Compound assignments

[Aureal]

Another little improvement to the QB64's syntax, in order to make it a bit less cumbersome to type, using the C/C++ Compound assignments, and increment/decrement by one operators.

"a += b" would be the same as "a = a + b". Its barely noticeable when variable names are short, but when using long names, variables with types, or even nested types, that amount of code seems unnecessary to write.

Code: QB64: [Select]

1. myLongVariableName.myType.myNestedType = myLongVariableName.myType.myNestedType + myLongVariableName.myType.myNestedType

vs

Code: QB64: [Select]

1. myLongVariableName.myType.myNestedType += myLongVariableName.myType.myNestedType

Another good thing would be the ++ and -- operators for increment by one and decrement by one:

Code: QB64: [Select]

1. myLongVariableName.myType.myNestedType = myLongVariableName.myType.myNestedType + 1
2.  

vs

Code: QB64: [Select]

1. ++myLongVariableName.myType.myNestedType
2.  

[eoredson]

I agree! And I think there should be more than just c++ and c--
such as:

Multiply: c*=
Divide: c\=
IntDivide: c/=
Power: c^=

and some booleans:

And: c&=
Or: c|=
Not: c!=

etc.

But then again there should also be UDT arrays..

Erik.

[Calloway]

--snip--

This was added or is this a request?

[SkyCharger001]

all you need for a UDT array is a _MEM-block

[STxAxTIC]

I never been a fan of any of the ++ or -- notation, especially when the language lets you put the symbols on either side of the variable. What is so special about "1" anyway? Why don't we have +++ and --- to skip along by 2?

I have always thought that += and -= were pretty nice though, its just that QB64 doesn't need them. There are a handful of deep reasons that I won't rant about, so the cop-out explanation is: Seeing how anything that breaks QB45 compatibility would need an underscore by tradition, I don't think that _+= and _-= are visually appealing. Of course I'm half joking, but not the other half. I'm at least 51% confident that those with the proper chops to do so won't be adding any exotic assignment operators to QB64 at the end of the day.

Come to think of it, according to certain opinions that I think are correct, using the equal sign as an assignment operator is a design mistake repeated hundreds of times since its first instance. The next good language won't overload the = symbol.

[bplus]

I never been a fan of any of the ++ or -- notation, especially when the language lets you put the symbols on either side of the variable. What is so special about "1" anyway? Why don't we have +++ and --- to skip along by 2?

I have always thought that += and -= were pretty nice though, its just that QB64 doesn't need them. There are a handful of deep reasons that I won't rant about, so the cop-out explanation is: Seeing how anything that breaks QB45 compatibility would need an underscore by tradition, I don't think that _+= and _-= are visually appealing. Of course I'm half joking, but not the other half. I'm at least 51% confident that those with the proper chops to do so won't be adding any exotic assignment operators to QB64 at the end of the day.

Come to think of it, according to certain opinions that I think are correct, using the equal sign as an assignment operator is a design mistake repeated hundreds of times since its first instance. The next good language won't overload the = symbol.

I was in favor of the idea until I read this. Considered me swayed the other way!

[bplus]

Come to think some more about it.

Compatibility issue is a cop-out. It's not going to interfere with old code. It might interfere with how things are handled under the hood, I don't know!

_-= or _+= is just plain ugly, a good way to turn off those in favor, but can't be serious.

To save myself from rant, I will take word for it that there are deeper issues to be considered, so I will leave it to the tech guys to discuss those issues.

[SMcNeill]

Honestly, I think if somebody is writing such long variable names that it's a hindrance to use them in their program, then they need to rethink those names.

MyLongArseVariableType.SubType.Identifier = MyLongArseVariableType.SubType.Identifier + 1 isn't much more to type than ++MyLongArseVariableType.SubType.Identifier...

Here's how you do it:

1) Type in "MyLongArseVariableType.SubType.Identifier"
2) Hold down mouse button, highlight that name.
3) Press "Ctrl + C"
4) Type in "="
5) Press "Ctrl + V"
6) Type in " + 1"
7) Hit ENTER

If you're typing in that long name over and over, you're just working yourself to death.  An even easier trick:  Use "LAVN1" for the "Long Arse Variable Number 1" when writing your program.  Then, before publishing or sharing the code, Edit and Replace All "LAVN1" instances with the actual name, to make the source more readable for others.

X += Y is moving away from BASIC and onwards towards C.  It's not something I'd ever add into the code personally, and, like Stx, I don't think anyone else is working towards pushing those changes into the language.

[FellippeHeitor]

X += Y is moving away from BASIC and onwards towards C.  It's not something I'd ever add into the code personally, and, like Stx, I don't think anyone else is working towards pushing those changes into the language.

Ditto.

[bplus]

May I ask how a change is made and who goes about doing it?

I mean we may be just wasting our time with all these opinions.

I really doubt it is a democratic process. And those who have technical knowledge of what an actual change involves certainly carry more weight with their opinions (hopefully). But then there is the Tradition thing which is all opinion and there a community may have more equal input.

All this supposes the changer listens and weighs-in all these factors.

[SMcNeill]

May I ask how a change is made and who goes about doing it?

I mean we may be just wasting our time with all these opinions.

I really doubt it is a democratic process. And those who have technical knowledge of what an actual change involves certainly carry more weight with their opinions (hopefully). But then there is the Tradition thing which is all opinion and there a community may have more equal input.

All this supposes the changer listens and weighs-in all these factors.

Anyone Galleon has approved write-permission to the repo, can make changes.  AFAIK, that's basically me, Fellippe, and Luke -- unless somebody else was added which I didn't notice.

As for WHAT changes are pushed, Galleon is a very free spirited guy with the source code.  Just about anything goes, but you have to figure out how to do it yourself.  (With a few exceptions which he's ruled out for the language, such as inline streaming of other languages.)

Generally, we listen to all suggestions, and we're generally nice enough guys to say, "Let me look into that.", or, "Not me, maybe one of the others will"...  Some suggestions we can help work into the language, some we can't, but we tend to try and keep a two-way line of communication open as much as possible to not leave anyone in the dark.  ;)

Only 100% guaranteed way to get changes to the language: 
1) Get write permission to the github repo from Galleon.
2) Make the changes yourself.
3) Push those changes into the repo. 

[bplus]

Thanks!

Ah the legendary Galleon who is supposed to be fixing [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there], I've heard of along with Fellippe and SMcNeill at that site.

Who is Luke? Has he posted here? (no members Index, yet?)

Have I run into him at The QB64 Edition?

Append: Oh here he is! 5 posts, sorry old age is having it's effect.