I personally am in favor of the addition of the operators mentioned above including the pre versions such at ++x and --x.
Some of the comments above state they would not use them. That’s fine. But in one example:
DoSomething( x++ )
This is a much nicer thing then having to write:
DoSomething( x )
x = x + 1
I think with any language, you still have to think about what you are doing. The addition of operators doesn’t add to bugs and problems, it is incorrect logic that adds to bugs and problems.
I also would like to see all of the above, as well as ++ and --, in both pre-and post variable form.
If you don’t want to use them, don’t, but not having this is something that has bugged me about Xojo since I started using it, something like 15 years ago. I’m used to them from PHP where I did a lot of coding in the early 2000s and I still catch myself coding loops like that in Xojo because it comes naturally.
Nobody is advocating a switch to new syntax, just adding support for it for those who want it.
I think it is going to be more difficult for Xojo to enable “function( X++ )”, which requires inline operators, however, that’s for them to consider.
Not true until yesterday at least
The designers reasoning were “or we support it exactly as known in other languages, or don’t support at all”
Open for future implementation (or not), but right now it isn’t.
FWW this has been requested a trillion times. Xojo Inc has states several times it has no plans to add this (mostly because it roots are BASIC).
Move on…
You are correct. My mistake, sorry.
We had to change a lot of things from API1 to API2 because Xojo said it was important to have a language more similar to other language. I don’t care about A ++ or A +=, I don’t think I will use it and continue with A = A + 1. But I’m agree Xojo should add this feature. It won’t annoy people who don’t want to use it. I don’t think it will add bug as sometimes do some features. The problem is only the time Xojo will spend to add this feature.
Xojo changed its name from RealBasic to RealStudio and then Xojo to forget the word “Basic” and look more modern.
To behonest .. Xojo is an awful name (and not really
sticking in people’s minds)
Anyhow, they do stick to typical BASIC syntax for about everything and I think that is good. Keep it simple is what BASIC is all about.
I don’t think that was the main reason, though.
10 PRINT “EVOLVE”
20 GOTO 10
Languages need to evolve and keep up with modern things to stay alive else their user base just drops to nothing. There is no such thing as keep them as they were.
Else basic would be like Rick pointed out above, and Basic would have no classes, controls, delegates, or much of anything.
Fair point. But not sure if operators would be a useful addition.
That is usually the case, that things are not for “everyone”.
For example C# language has progressed at insane rate. To the point that I as full time C# developer by profession don’t know everything in it. But that is all right. I pick and choose what I use. Or some things I don’t know about yet, and might realize later and that also is all right.
Its nature of language improvements usually that you do not have to use it if it don’t fit you. You don’t have to use for each you can still use basic for loops.
Ditto for Swift
Well, if they would consider this, they should for sure do it correctly and implement ++x and x++ (which are different).
My 2c… been using this for 20 years, never once been unable to write code due to the lack of them.
Xojo has more important things to do, I feel.
I think assignment operators like += would be nice, but like other people have said, I’ve actually got used to not having them so I’m not sure how much attention is likely to be given to implementing them.
I actually have a bigger issue with the lack of bitshift operators in Xojo and having to use the Bitwise module methods in their place:
crc = IF((crc AND &h1)=&h1, Bitwise.ShiftRight(crc,1,32) XOR &h82f63b78, Bitwise.ShiftRight(crc,1,32))
would be much neater to code as:
crc = IF((crc AND &h1)=&h1, (crc >> 1) XOR &h82f63b78, crc >> 1)
Well, adding missing commands or features make languages evolving, indeed. Adding things from other languages that can already be done in place is unnecessary.
This is missing code sharing consideration, I’d say.
Your not getting any “code sharing” or at least less and less if everyone has moved on because the language cannot keep up.
That’s “part” of the full spec of VB expression and assignment operators. But it is one level above += and -= in the difficult level of implementation, probably.
To implement <<= and >>=, first they need to implement << and >>
Any operator used inside the expression evaluator is much more complex than one assignment operator that is basically a expression solver (already existent) + a store result.
What’s the difference of “=” and “+=” ?
x = 1 → move 1 to [ x ]
x += 1 → add 1 to [ x ]
x = expression() → call expression_solver pushing result, pop result and move to [ x ]
x += expression() → call expression_solver pushing result, pop result and add to [ x ]
Theoretically += and -= can be implemented in few hours, maybe just few minutes, depending on how deep the dev knows the code involved, how rested, happy and caffeinated he is too.
Once done, it opens the doors for the rest in another release.