Godot: Small additions to GDScript // var++ and switch()

[macramole]

++ and -- operators

Being able to do:

var a
a++
a--

instead of

a+=1
a-=1

switch

also, a switch() would be good as well.. as in

func a(param):
    switch(param):
      case "a":
         break
      case "b"
          ...

$(NodePath) function

alias of get_node(NodePath)

It looks like jQuery so it's more fun and familiar to Javascript programmers

I think there is a $"NodePath" but it looks kinda weird to me :P

[Spooner]

Python doesn't have either of the first, so it doesn't really make sense to add to GDScript.

[macramole]

That doesn't sound like a strong argument.. Python is Python, GDScript is GDScript, they are similar but also different.. I was expecting something like "it would be ok but noone is willing to waste his time on this"

[reduz]

i'm not against it but there are more important things to spend development
time on at the moment

On Tue, Jan 6, 2015 at 7:45 PM, macramole [email protected] wrote:

That doesn't sound like a strong argument.. Python is Python, GDScript is
GDScript, they are similar but also different.. I was expecting something
like "it would be ok but noone is willing to waste his time on this"

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1107#issuecomment-68948675.

[macramole]

That's what I thought.. I've been looking the source code to see if I could add it, but the parser code is too hardcore for me.. This is super low priority of course.

I would suggest to put comments like JavaDocs or something in source code's methods, it will be much easier for the community to help that way

[akien-mga]

Switch could be pretty interesting, and I guess i++ and i-- wouldn't hurt.
I don't think $(NodePath) would be a good addition though, it's clearly inconsistent with the rest of the GDScript style.

[ghost]

i noticed these were missing and also the != seems to also be missing

i kinda like the minimal approach of gdscript i don't mind they are missing .

now switch case might be useful

[akien-mga]

i noticed these were missing and also the != seems to also be missing

As far as I know != works fine, see e.g. https://github.com/akien-mga/dynadungeons/blob/master/scripts/bomb.gd#L99

[ghost]

my fault sorry true != does exist

[bojidar-bg]

I'd agree that switch is useful sometimes, though I think ++ and -- are not good ideas. Consider

func decrease_health():
    health--

vs.

func decrease_health(amount):
    health-=amount

Now, if -- was supported, I would have done the first one, since it would feel "correct" on the first glance. But, if it isn't supported, I would have more reason to do the second, which is much better in the long run usually.

[luluco250]

That doesn't make any sense, why would it "feel 'correct'" to not specify the amount of health you wish to decrease just because the -- operator was supported?

Honestly those kind of operators are mostly for convenience, surely not priority, but the example you made makes no sense as to why they're not good ideas.

[ghost]

I think overload operator has other issues like for example ++i and i++ are the same? From my knowledge they are not. First adds then checks second checks then adds. But that depends on the language as well. Also can you overload and overload ? ++++i i++++ ? You get into weird things. I like GD Script the way. Much more simple and easy to understand.

[vnen]

I'm also against the ++ and -- operators. The only gain is typing one less character and it decreases readability.

I'm good with the switch statement though. switch and case are already reserved words, so there's no compatibility problem.

[PokemonAshLovesMyTurkeyAndILikeYouTwo]

Can we please for the love of god get switch and the ternary operator before 2.2?

Can I just pay Juan to go on vacation and code it in or something, really don't care at this point

[27thLiz]

A better switch is implemented via the match keyword and the $ get_node() shortcut is also supported now.
So this leaves the ++ and -- operators, which are still up for discussion.
I'm personally also against them.

[akien-mga]

Most core contributors were against ++ and --, so closing.

[Shavais]

So concerning increment and decrement operators ++ and --, the arguments against them are

1. Python doesn't have them (and its easier to learn GDScript if its as much like Python as possible).
2. It detracts from code clarity (i++ is different from ++i, for example, which is nuanced and twiddly).
3. It might create a hammer that'll get used on screws (i++ is less generally applicable than m += v).
4. It creates the potential for ambiguity (what do you do with ++++i---- ).

but..

1. Is GDScript really intended to be all that much like Python? Is it ever going to have list comprehensions, dictionary comprehensions, generators, decorators or even try/except? The setget syntax is completely different from Python's __get__ and __set__ functions. But isn't GDScript intended to be friendlier to C++ developers than Python is? It certainly has less C++ interfacing overhead, why not carry some of that friendliness into the language itself?

2. i++ returns i's value before incrementing i, ++i returns i's value after incrementing it - that's not really all that unclear is it? Aren't most developers quite familiar with that general idiom?

3. Even though member += value is more generally applicable than i++, still, aren't there plenty of occassions when i++ is appropriate? Is it more important to create a product that coddles inexperienced developers, or is it more important to create a product of superior quality? In the case of a scripting language, doesn't quality = power = performance * rapidity? Wouldn't increment and decrement operators improve rapidity (slightly) without sacrificing any performance? Obviously the maintainability and interface-ability of the language implementation code is another big quality concern; would implementing increment and decrement operators have a negative impact on that?

4. The increment/decrement operators are shorthand forms of assignments, which require assignable targets (lvalues). At least that's true in procedural (as opposed to functional or declarative) languages, as far as I know? As such, --(--i) or (i++)++ would be attempts to assign to an expression, right? I don't think any developer who is used to procedural languages would expect that to be legal syntax?

Unity has a ton of money and 100+ (if my impression is correct) paid full time developers to throw at the goal of spreading familiarity with their product across masses of young inexperienced developers in order to one day reap the benefits of serving the ones that grow up to do successful projects. I would hope that Godot would not try too hard to compete with them in doing that?

I would like to hope that Godot would instead aim at being the superior choice for Unity developers when they grow up and become dissillusioned with Unity because of .NET, which must JIT and garbage collect and is primarily strictly typed and therefore much less rapid, and carries an enormous deployment payload and so on, and because of the ridiculous difficulty involved in altering the behaviour of Unity itself. Those developers will be looking for increased rapidness without sacrificing performance and quality.

What they'll really want is increased rapidness, performance and quality - which I believe Godot is uniquely positioned to eventually deliver. Because Unity is encumbered by .NET and Unreal has no GDScript and its implementors have no appreciation for its value.

Speaking of quality, the smoothness of the Blender workflow (that I've encountered thus far) is way, way better with Godot than it is with Unity! Omg! I cannot thank you guys enough for that! Thank you thank you thank you!

I am very much looking forward to the improvements in the 3D arena that 3.x has coming, and I sure wouldn't want anyone to spend any effort on something like this when they could be spending effort on something like that. Absolutely not.

But I see GDScript as being Godot's primary advantage over its competitors, and I hope that going forward, GDScript will be a First Class Citizen and won't be encumbered too much by any requirement of coddling inexperienced developers.

I'm not here because I don't know C++. I'm not here because I'd be likely to write i++ when I should write member += value or expect ----i++++ to be valid syntax or choose GDScript over C++ when I need to visit every vertex of a mesh or something. I'm here because I dream of creating high performance, high quality games without having to become a small cog in a giant conglomerate to do it.

[xKamuna]

I use ++ and -- a lot.
Example: "viewportTex" + str(numTextures++) instead of
"viewportTex" + str(numTextures)
numTextures += 1
Saves lines, and sometimes makes code more compact and readable.
Same for doing = and such in an if/while/for statement (those could give out warnings if they aren't in parenthesis by default, if you wish).
Would love for these features to come to GDScript.

[TheRealGammer]

What none of yall seem to understand is that machine code (as in processors) has an instruction called inc and dec, both of which are completely independent of add and sub, so adding a -- and an ++ operator is trivial for speed and efficiency. I'm working on a new programming language entirely, which I will add godot support for if any of you are interested. It's called C♭ (like if you get the music reference (also C#)). Now for those of you who don't care about C♭ and just want the damn -- & ++ ops, then stay tuned for a release.

[ArdaE]

@TheRealGammer That can't be an argument for having ++/-- support in a language. If runtime performance is a concern, a very basic optimization can be added to easily convert additions/subtractions of literal 1 to increment/decrement bytecodes when integers are involved. Also note that GDScripts compiles to bytecode as far as I know, not machine code, so you'd only get the benefit of avoiding an extra memory fetch if ++/-- are added to the bytecode instruction set of Godot.

P.S. I'm not for or against ++/-- in GDScript. Although I use them often in C++ for maximum efficiency, I don't care for them in a bytecode-interpreting language like GDScript. I'd use them if they're there, as they can still help simplify code in some cases, but wouldn't miss them.

[TheRealGammer]

@ArdaE actually you have a very good point. I found that out a while ago, that GDS doesn’t compile to machine code. This really disappointed me so it gave me extra incentive to work on my game engine which is in C♭ which is a language I made. For more info, message me.

EDIT:
Oh also I used to be an arrogant **, so don’t take the way I used too talk to seriously.