Describe the project you are working on:
Not important
Describe the problem or limitation you are having in your project:
for declaring the name of the class we use "class_name MyClass"
but for declaring internal classes keyword "class InternalClass"
Describe the feature/enhancement and how it helps to overcome the problem or limitation:
the idea is to remove "class_name" and use only "class"
By doing this we can throw out one keyword
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
If we want to set a name for a class we can check if there is no class body declaration then it is setting a name for the class
class MyClass #this obviously that it is giving a name to the class
class InternalClass:
func MyFunc:
pass
this is an internal class declaration so no confusing
If this enhancement will not be used often, can it be worked around with a few lines of script?:
no
Is there a reason why this should be core and not an add-on in the asset library?:
related to GDScript syntax
A very similar thing was discussed in #209. The consensus was that changing the current way for the sake of changing has little actual benefit. And using class instead of class_name would introduce confusion with the declaration of inner classes as per this comment.
By doing this we can throw out one keyword
That's not a benefit in and of itself, though. Different keywords are good. Different keywords make code less ambiguous. We shouldn't aim to make the language as concise as possible. We should aim to make it as clear as possible.
One thing I see that could be discussed here that wasn't covered in #209 is removing the underscore in class_name and making it classname. We already have onready, remotesync, mastersync, puppetsync without underscores, so the change would make it more consistent.
icon 'game/icons/icon.ico' could be added as @icon metadata
@icon='game/icons/icon.ico'
class MyNode extends Node
internal classes provided in the old way
class InternalClass
A very similar thing was discussed in #209. The consensus was that changing the current way for the sake of changing has little actual benefit. And using
classinstead ofclass_namewould introduce confusion with the declaration of inner classes as per this comment.
There are actually cases where class_name creates problems with existing method names/properties: godotengine/godot#43255. Of course, those can be renamed to something else, but by using class those kind of errors can be eliminated completely, because it's unlikely that someone would want to bind a property with class as identifier due to how C++ works. Also lets not forget about C++ modules which may be cursed by limitations like this.
Also, https://github.com/godotengine/godot-proposals/issues/209#issuecomment-624193796 only describes that it's "more difficult to implement" (it's just a matter of work) and that it would somehow "create confusion" with inner classes. I've never had to declare a class which only contains other nested inner classes so I consider this as corner case, I'd rather prefer to have consistency in syntax for declaring classes, even if this requires some parsing nuances to be overcome.
Again, the fact that this proposal is created which is basically #209 only proves that there's indeed a problem.
@Xrayez This particular proposal didn't even describe any problem, though, just a random wish. It just states that we must use two different keywords for two different cases. This does not sound like a problem to me.
As far as confusion, if that's vnen you are quoting, he was probably talking about confusing logic in the parser, as this change would make the class keyword ambiguous.
Bottom line is, class_name is probably a misnomer, but it's not the same as class. I'm down with renaming it to something like global.
Is it necessary for the gdscript to have unnamed classes ?
Why not automatically assign the name of the file ?
class_name doesn't just name a script, it registers it in global scope. Not every script needs to be globally accessible. Most don't.
I really agree class_name is confusing and repetitive.
we already have a export keyword and annotation lets use it.
I also want to see the ability to have multiple nodes defined per script
export class MyCustomNode extends Node2D:
func _ready():
pass
export class MyCustomNode2 extends Spatial:
func _ready():
pass
this would work well with #615
I know some people don't want the extra level of indentation but every language has it, that's just how classes work
Edit: for people wanting private/unnamed classes something like this could work..
class _ extends Node2D: or class _MyCustomNode extends Node2D:
also there is a suggestion about accessor keywords
Most helpful comment
A very similar thing was discussed in #209. The consensus was that changing the current way for the sake of changing has little actual benefit. And using
classinstead ofclass_namewould introduce confusion with the declaration of inner classes as per this comment.