JavaScript-ing it, I need to get with it

[mnrvovrfc]

https://qb64phoenix.com/forum/showthread...66#pid9266

This thread exists because I didn't want to reply to that post, and I selfishly didn't want to post on the dedicated thread about the subject.

Good job with this project, surprised that it's as deep as it is in such a short time. Normally I don't like stunts done by clunky web browsers but this interested me. I visited the page on Github to learn about support for QB64(PE) keywords. These are just my observations.

• "COMMAND$" - not even a special "global" dialog to put in its value? Some programs depend on this, including all-uppercase return value, and it might be difficult to change away from it. Might not have to worry a lot about "COMMAND$(1)" or alike. OTOH Linux is very lame about this sometimes, limiting terminal command line to a maximum of 255 characters.
  
• "IF... THEN" - clarify that it has to be "IF (condition) THEN GOTO (linenum/label)", or "GOTO" cannot be used at all? (OK discovered below "GOTO" and labels aren't even supported.) Does this mean only block "IF" could work? No problem for me but some old programs would need extensive revision then, you know how much colons were loved back then...
  
• "LOCATE" - does this mean changing the cursor shape? Because this is a bit sad this day and age. I mean in graphics mode "druw yer own kersair for krissakes"...
  
• "OPEN FOR RANDOM AS" - this should be easy to implement one way. "TYPE... END TYPE" is supported, am I correct? It must have to do with a security issue. Entire files could be "dowloaded" which isn't as useful to me and I could never get to grips with Internet functionality in QB64PE.
  
• "SELECT CASE" - what is "EVERYCASE"? Do you mean "CASE ELSE"? Must be Visual Basic tendency.
  
• "TIMER" - a few QB64 programs will be broken because of this. So this might mean the QB64-only edition of "ON TIMER" isn't supported neither.
  
• "_MOUSEINPUT" - LOL so this is like being on a Macintosh.
  
• "_OS$" - I think this should work like in normal QB64, some programs depend on this information and don't use the preprocessor.
  

A few other things:
Sub parameters are passed only by value: this is one reason why I'll have difficulty with this package. LOL I like using "SUBs" instead of "FUNCTIONs" to return values, especially more than one value since I also like to program in Lua.
"GOSUB... RETURN" not supported: yeech!
Function return could be array, associative arrays support: don't need unless the above two are fixed!

Errm... I understand the tendency toward Visual Basic, but I guess this isn't for converting programs created before M$ came up with that product. No spaghetti code allowed! Also give them no choice with "OPTION _EXPLICIT" always enabled. Some people with bad habits made by Q(uick)BASIC are going to be alienated, however.

As I've said, these are just observations (opinions).

[SMcNeill]

https://qb64phoenix.com/qb64wiki/index.php/SELECT_CASE -- QB64 supports SELECT EVERYCASE as well, just FYI.

[mnrvovrfc]

https://qb64phoenix.com/qb64wiki/index.php/SELECT_CASE -- QB64 supports SELECT EVERYCASE as well, just FYI.

Thank you for the heads up! This is a lot like not using "break;" in "switch()" in C.

[CharlieJV]

I wanted to be careful not to clutter this thread, so I created the "Thoughts on BAM and QBJS (etc.)" thread as a kind of sidebar discussion in case there is interest in that.

[Pete]

https://qb64phoenix.com/qb64wiki/index.php/SELECT_CASE -- QB64 supports SELECT EVERYCASE as well, just FYI.

And soon Steve will be adding the even more powerful keyword, SELECT CASES

What Tuesday will that one premier on again, Steve?

Pete

[PhilOfPerth]

From my (very) limited knowledge, Select EveryCase would be different from Case Else, in that it would also include the cases already selected. Not sure of an application for this though.

[Pete]

Code: (Select All)

INPUT "Input 1, 2, or 3: "; a
SELECT EVERYCASE a
    CASE IS > 1
        PRINT a; "> 1"
    CASE IS < 2
        PRINT a; "< 2"
    CASE IS < 3
        PRINT a; "< 3"
    CASE ELSE
        PRINT "I don't know what a is!"
END SELECT
SLEEP
CLS
RUN

[CharlieJV]

Code: (Select All)

INPUT "Input 1, 2, or 3: "; a
SELECT EVERYCASE a
    CASE IS > 1
        PRINT a; "> 1"
    CASE IS < 2
        PRINT a; "< 2"
    CASE IS < 3
        PRINT a; "< 3"
    CASE ELSE
        PRINT "I don't know what a is!"
END SELECT
SLEEP
CLS
RUN

I think I'm more confused than I was before.  (But that easy to me happens.)

What does "SELECT EVERYCASE" do vs "SELECT CASE" ?

[Pete]

SELECT CASE moves the program flow through just one condition in the block. SELECT EVERYCASE moves your program flow through every case in the block that is true. SELECT EVERYCASE is therefore useful during some instances where the coder would otherwise need to add more conditional statements to handle all possible conditions.

Pete

[mnrvovrfc]

One has to pretend there is a forced "FALLTHROUGH" keyword, while "SELECT EVERYCASE" didn't exist. Because that's what it would have required otherwise.

Code: (Select All)

INPUT "Input 1, 2, or 3: "; a
SELECT CASE a
    CASE IS > 1
        PRINT a; "> 1"
        '_FALLTHROUGH
    CASE IS < 2
        PRINT a; "< 2"
        '_FALLTHROUGH
    CASE IS < 3
        PRINT a; "< 3"
    CASE ELSE
        PRINT "I don't know what a is!"
END SELECT

When "SELECT CASE... END SELECT" was invented, it could have been fashioned just like "switch()" in C, thus requiring "EXIT SELECT" or "BREAK" statement at the end of each "CASE" block. The opposite is true. But the need arose where fallthrough was needed, either potentially for all cases above "CASE ELSE", or for just "CASE ELSE".

I'm taking my own topic off course... but the QBJS listing of supported QB64 keywords got my attention about a few things.