Godot-proposals: Remove the `class_name` keyword and use only `class`

Created on 15 Nov 2020  路  9Comments  路  Source: godotengine/godot-proposals

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

gdscript

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 class instead of class_name would introduce confusion with the declaration of inner classes as per this comment.

All 9 comments

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 class instead of class_name would 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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

PLyczkowski picture PLyczkowski  路  3Comments

davthedev picture davthedev  路  3Comments

aaronfranke picture aaronfranke  路  3Comments

Torguen picture Torguen  路  3Comments

WilliamTambellini picture WilliamTambellini  路  3Comments