WITH/END WITH?

[bobalooie]

Back in my VB6 days I would frequently make use of a WITH/END WITH block when I had UDTs with a lot of members. I believe it's still available in the Visual Studio flavor as well. How difficult would it be to implement this in QB64PE?

[hsiangch_ong]

you could write a preprocessor of "dot-bas" code, like i have done.

how difficult it is to use search-and-replace?  or creating temporary "helper" functions which are like "get" and "set" property methods?

this "with" block like pascal is a real headache.  could make code difficult to debug.  especially with lazy naming of fields and variables.

---

this is a short but silly example.  temporarily use subprograms like "properties."  in another programming language which supports oop.  then when you think you are ready for a "release" version.  remove those subprograms.  do search-and-replace on the subprogram calls.  however this could get messy, if you don't like using regular expressions...

Code: (Select All)

type mytype
    ident as string * 128
    offzet as _integer64
    verylongfield as _float
end type

dim shared container(1 to 100) as mytype

pvlfield 1, 4.5
pident 1, "this is only a test"
print container(1).verylongfield
print vlfield(1)
print ident$(1)
end

function vlfield## (which as integer)
    vlfield## = container(which).verylongfield
end function

function ident$ (which as integer)
    ident$ = container(which).ident
end function

sub pvlfield (which as integer, what as _float)
    container(which).verylongfield = what
end sub

sub pident (which as integer, what as string)
    container(which).ident = left$(what, 128)
end sub

some oop coders in c++/python actually do things this way.  precisely because they have to use longish field names.  at least to indicate the type of a class field.  so it's easy to inherit from that class.

[hsiangch_ong]

WITH / END WITH isn’t just syntactic sugar — it affects name resolution, scoping, and how the compiler/parser rewrites member access.

said it better than i did.

that the turbo pascal developers.  were able to pull it off.  before "oop" became an "awesome" thing.  has to be praised very much.  while the creators of unix and "c".  have to be condemned for totally dismissing a "bondage" language.  that had a couple of features that in a funny way.  ended up in c++.

[Pete]

How about a MyType / Not MyType  

Sorry, couldn't resist, but good thoughts in this thread about keyword integration... Hmm, we really need an applause smiley.

Pete

[bplus]

Well lets ask AI

Using WITH/END WITH in QB64 Phoenix Edition (PE) would be a positive addition because it improves code readability and reduces the chance of typing errors, particularly when working with User-Defined Types (UDTs) that have many members.
Benefits of WITH/END WITH
Improved Readability: It allows you to perform a series of statements on a single object or UDT without having to specify the object's name repeatedly, making the code cleaner and easier to read.
Reduced Errors: By referencing the object only once, it minimizes potential typing errors in object names.
Potential Performance Gain (Historically): In older VB versions, using With...End With could offer a minor performance boost because the object's address reference was looked up only once at the beginning of the block, rather than for each property access. While this performance difference is likely negligible in modern compilers like QB64PE, the primary benefits are related to code maintenance and clarity.
Current Status in QB64PE
Currently, WITH/END WITH is not a supported feature in QB64PE's standard syntax, which primarily aims for compatibility with QuickBASIC 4.5. However, the idea has been discussed in the community forums, with users expressing a desire for this feature, especially those who frequently used it in VB6.
Recommendation
If you wish to see this feature officially implemented, the best approach is to engage with the developer community on the QB64 Phoenix Edition forum and the GitHub repository. The developers are actively adding enhancements and improvements, and community input can help prioritize new features.
In the meantime, a common workaround is to use a short, temporary variable as an alias for the object you are repeatedly accessing, though this is less elegant than a dedicated WITH block.

So nice work around idea, no?

[Pete]

Well just tell the motherboard ******* machine to implement it then!

Pete

- Everyone's a critic, but critics who can't code aren't worth 2-bits.

[NakedApe]

Dang, that AI knows this place well! 

[bplus]

OK here it is!

Implementing VB-style WITH...END WITH in QB64pe involves using macros or custom preprocessor directives, as QB64 doesn't natively support it; you'd define macros like #Define With(obj) obj. and #Define EndWith to substitute for the shorthand, then use qb64pe -c (compile) or qb64pe -x (execute) from a script or build system to process these, creating a clear pull request on GitHub by showing the original code and the transformed output, explaining how these macros simulate the VB functionality.
1. The QB64pe Code (Simulated WITH)
You'll use QB64's preprocessor features to mimic WITH.
qb64
'// WITH_SIMULATOR.BAS

#Define With(obj) obj.
#Define EndWith

' Original VB-style code (simulated):
' WITH mySprite
'    X = 100
'    Y = 200
'    Color = RGB(255, 0, 0)
' END WITH

' Translated by the macro:
DIM mySprite AS OBJECT
mySprite.X = 100
mySprite.Y = 200
mySprite.Color = RGB(255, 0, 0)

' Example with a real object (like a Window):
DIM myWindow AS _WINDOW
WITH myWindow
    .X = 0
    .Y = 0
    .Width = 800
    .Height = 600
END WITH
' (This will look like: myWindow.X=0, myWindow.Y=0, etc., after processing)

PRINT "Simulated WITH block executed!"

#Undefine With
#Undefine EndWith
2. How It Works (Preprocessor Magic)
#Define With(obj) obj. turns WITH mySprite into mySprite. (note the dot).
#Define EndWith just removes the line entirely.
When QB64 compiles, it sees mySprite. and understands you're accessing members of mySprite.
3. Preparing for Your GitHub Pull Request
Create a Branch: git checkout -b feature/with-syntax-support
Add Files: git add WITH_SIMULATOR.BAS
Commit: git commit -m "Add simulation for VB WITH/END WITH syntax"
Push: git push origin feature/with-syntax-support
4. In Your Pull Request Description
Title: "Feature: Implement VB-Style WITH/END WITH using Preprocessor Macros"
Description:
Explain the goal: bring familiar VB syntax to QB64 users.
Show the Original Code (using WITH...END WITH).
Show the Transformed Code (what the preprocessor makes it).
Explain the macros used (#Define With(obj) obj., #Define EndWith).
Mention the compilation command: qb64pe -c your_file.bas or qb64pe -x your_file.bas.
Link to relevant QB64 documentation or forum discussions if needed.
This approach provides a clear, executable solution that honors the requested VB style within the QB64 environment, perfect for a GitHub contribution.

[Pete]

It makes me want to erase all my code posts. I don't want to be the least bit responsible for bringing about the end of  when the machines take over. Oh wait, I forgot, you need FreeBASIC for that!

Pete

[hsiangch_ong]

the problem is.  getting other people to want to run.  an additional program.  besides "qb64pe" executable.  have the programmer.  remember to always run "that other program on my beautiful code."  if it should be preprocessed.

i have done this before.  but it was many years ago.  i was getting an impressive mess.  because i also desired to fake _continue.  before it became a reality in qb64.

i also desired to include into my preprocessor.  something like a "loop list" processor.  something like this:

Code: (Select All)

dim item as string
with item, oranges pears squash peppers diamonds bananas lemons coal do
    if lcase$(item) = "coal" then
        print "You've been programming something other than BASIC for too long!"
    end if
end with

have to instead put those items.  into a string array.  or use read / data combination.

the post by @ClarettaBrown above.  was in english when i last replied.  is my mind playing tricks on me?!