Swap the names of the engine's internal "abstract" and "virtual"

[aaronfranke]

Describe the project you are working on

Godot itself.

Describe the problem or limitation you are having in your project

Not a limitation with a project, just something that I think is needlessly confusing.

Godot has macros for registering "abstract" classes and "virtual" classes.

• Abstract classes cannot be instantiated period, and cannot be extended by script or GDExtension.
• Virtual classes can be instantiated by the engine on a technical level, so they can be extended by script or GDExtension. However, in every other regard, they appear to the user the same as abstract.

Now, on the C++ side. C++ has a keyword called virtual that indicates a function should be a part of the vtable, a table of function pointers, which allows derived classes to override the function. C++ provides 2 options here:

• A virtual function can be given a default implementation that is used if the function is not overridden.
• A virtual function can have = 0; after its definition to indicate it has no default implementation. Without an implementation defined, the class cannot be instantiated, so this means it is required to be overridden in defined classes.

In typical C++ terminology, a function with = 0; is called a "pure virtual function". However, Godot calls a class with these "abstract". Godot had these first before the other one was added in Godot 4.0 for GDExtension.

In the future, with PR godotengine/godot#67777, the plan is to add an abstract keyword to GDScript. This will make a class abstract, but this is equivalent to what Godot calls "virtual", since the engine can still technically instantiate the class, and it can be extended by other scripts.

Basically, the problem is that these names seem to be completely swapped. A class with "pure virtual" being called "abstract" makes sense on its own, but since we have 2 different types of abstract classes, we should use the word "abstract" for what users expect abstract classes to be (classes that can be extended), and use the word "virtual" to match C++ pure virtual.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Swap the names of the internal GDREGISTER_ABSTRACT_CLASS and GDREGISTER_VIRTUAL_CLASS macros, and any other mentions of "abstract" and "virtual". In the end, "abstract" should be one that can technically be instantiated by the engine, can be extended in script and GDExtension, and matches GDScript abstract. While "virtual" should be the C++ "pure virtual" that cannot be instantiated by the engine, cannot be extended by script or GDExtension, and is the one that differs from GDScript abstract.

This will break compatibility for some third-party modules and GDExtensions, but it won't affect user scripts and projects.

Also note, when I first opened PR godotengine/godot#67777, I initially used the keyword "virtual" to match the engine's macros. However, feedback from users has been overwhelming that "abstract" is a better name. And you know what, I completely agree. I wasn't sure when I opened the PR, but the more I think about it, the more I am convinced that the word "abstract" is better to use for things that are actually extendable by user scripts or GDExtension, and we can use "virtual" for the C++ pure virtual stuff that can't be instantiated by the engine due to internal technical limitations.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The code change is to rename things, so this question doesn't really apply.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It can be easily worked around. You can just ignore the problem and use the current names.

Is there a reason why this should be core and not an add-on in the asset library?

This is a core part of the engine.

[ArchercatNEO]

As a C# user which has clear definitions of virtual/abstract it seems like godot internal abstract classes do not behave like good abstract classes which lead to this confusion.

To me "abstract class" means can be extended by any class, but not able to be instantiated in any way.
A "virtual class" means a class that can be extended or instantiated.
A "sealed class" (not present here) is a class that can be instantiated but not extended by any class

Then for methods
A "virtual method" is a method that is part of the object's vtable and can be overriden by any derived class. These methods have a default implementation.
An "abstract method" is a virtual method with no implementation. This means a vtable cannot be constructed so the class it is a member of must be abstract.

If we look at godot's definitions of abstract/virtual there are 2 sides: engine and user (scripting/gdextension)

At the engine level

• Abstract classes are abstract classes within c# terminology
• Virtual classes are just standard classes

At the user level

• Abstract classes fit no definition. They cannot be instantiated (abstract) and cannot be extended (sealed) this combination is confusing, unhelpful and doesn't correlate with wider use of "abstract"
• Virtual classes are abstract classes because they can be extended but not instantiated

This is where confusion lies. abstract/virtual mean different things at the engine side and user side.

My suggestion is that instead of swapping the names at engine level (to confuse everyone with prior understanding of these terms) we rename how they are presented to the user. Engine side current use of abstract/virtual is preserved.

In node type selection (and any other significant UI locations)

• Abstract is renamed to "internal" (or other term with less overloading barring virtual)
• Virtual is renamed to "abstract"

This way the engine keeps it's internal abstract/virtual separation in line with standard use of abstract and users get class keywords that more closely align with how abstract is used in wider programming.

Unfortunately I am not aware if/how the GDREGISTER_ABSTRACT_CLASS macros are exposed in gdextension and how they are then exposed to scripting so instead I propose that abstract/virtual should preserve their definitions within a context (engine/gdextension/scripting) and at the point of contact be renamed to fit what the other context expects of such classes.

[AThousandShips]

This will break compatibility for some third-party modules, but it won't affect user scripts, projects, or GDExtensions.

How will this not break compatibility with GDExtension? It uses the same system of the virtual/abstract, you can register abstract classes in GDExtension as well

[aaronfranke]

@AThousandShips Oh, never mind. Since those ClassDB APIs exist, yeah this would break compatibility there.

[aaronfranke]

Another option would be to choose new names instead of simply swapping the names. For example, the "engine internal can't be extended" classes can have the macro named GDREGISTER_PURE_VIRTUAL_CLASS. Or we could use names like "virtual abstract", "unextendable abstract", "extendable abstract", "sealed", "final", etc. If we use a new name like this, we can partially migrate to it without breaking compatibility, by allowing both old and new names.

[Innokentiy-Alaytsev]

I don't think that calling a class that can't be extended "pure virtual" is correct: in C++ you mush implement pure virtual functions, thus extending the class declaring those. Neither "abstract" nor "virtual" keywords are applicable for classes that can't be extended since both keywords represent extendable classes in most contexts (I guess). In general, having classes with virtual functions that are extended inside the engine or extension, but are not extendible through GDScript seems odd. I believe that it has to do with performance concerns or something similar, but still.

[aaronfranke]

@Innokentiy-Alaytsev The extendability is bundled together between scripts and extensions. If it can't be extended from script, it also can't be extended from GDExtension.

[Innokentiy-Alaytsev]

I can register a class with godot::ClassDB::register_abstract_class(). This class will not be extendible from GDScript, from what I see. At very least, it will be grayed-out when selecting the base class. But nothing prevents me from extending it from the same GDExtension. I haven't tried extending standard Godot classes registered as abstract though.

EDIT: The class registered as abstract will not show at all when selecting a base class for script. A class registered as virtual will show up, but will be grayed-out, and inheriting it from UI will not be possible (which is strange, to say the least).

[aaronfranke]

@Innokentiy-Alaytsev Ah, that's correct. So that is is another state to consider. What I was referring to is things that are abstract in the engine's C++ code, which then cannot be extended from GDExtension in script.

A class registered as virtual will show up, but will be grayed-out, and inheriting it from UI will not be possible (which is strange, to say the least).

This is intentional because we don't want users to create nodes from these classes, they are only meant to be extended, and then the extended classes can be instanced.

[Innokentiy-Alaytsev]

Ah, that's correct. So that is is another state to consider. What I was referring to is things that are abstract in the engine's C++ code, which then cannot be extended from GDExtension in script.

I might be misunderstanding something, but I'm not sure how registering classes as abstract inside the engine will prevent from inheriting them in C++ GDExtension, at least from C++ side of things.

This is intentional because we don't want users to create nodes from these classes, they are only meant to be extended, and then the extended classes can be instanced.

I wasn't talking about instancing a node. I was talking about the New Script dialog. There is an option to choose the base class from the script. When you click on a tree button the class tree is shown. In this class tree abstract classes are not shown at all, while virtual classes are shown but cannot be picked as the base class for the new class. I think this behaviour is strange, at least for virtual classes.

BTW, quick googling didn't show any official documentation on abstract and virtual classes. Godot sources have very few comments and no documentation comments. This makes it hard to understand the intentions behind some aspects of its inner workings.

[aaronfranke]

but I'm not sure how registering classes as abstract inside the engine will prevent from inheriting them in C++ GDExtension, at least from C++ side of things.

It's not possible because internally when Godot creates a node from a GDExtension it effectively creates the internal class it's based on and then "attaches a script" to it for the GDExtension. Therefore, the engine needs to be able to instantiate the internal class it's based on. If you try to make a GDExtension extending CanvasItem, for example, it doesn't work. godotengine/godot#67510

I was talking about the New Script dialog. There is an option to choose the base class from the script.

That's a bug then, users should be allowed to select the currently-named virtual types in that dialog.