GDScript: Allow overriding default values of base class variables

[dalexeev]

• Closes Allow ability to override parent variables godot-proposals#338.

@override var script_var: int = f(2)
@onready @override var name: StringName = &"Test"

TODO: Implement proposal godotengine/godot-proposals#8045 (only possible for inline setters/getters).

[Mickeon]

How far does the @override go? Would it actually let you override, say, export properties as well?

Also I see my PR to highlight overridden properties is being put to even better use now.

[dalexeev]

How far does the @override go? Would it actually let you override, say, export properties as well?

Variable overriding is reasonably quite limited:

• You cannot change the variable type.
• You cannot override static variables because they belong to their classes, not to the instance.
• You cannot change or remove setter/getter because GDScript is a fairly dynamic language and it would be weird to have different behavior depending on the type and casts inferred by the analyzer.

The only thing this feature is really intended for, is to change the default value of a variable in an inherited class, just like it is possible in native classes. This can be useful because the overriden default value is shown in the documentation and in the Inspector (the latter is not yet debugged). Also it shouldn't require @tool.

Note that the current implementation the default value is not replaced, just the inherited implicit initializer is executed after the base implicit initializer. That is, the variable will be assigned twice (or more, as many overrides). In all initializations the setter will not be called, since there is an exception for the initializer. I'm not sure if this is a good thing, but I don't see how we could implement it without complicating the compiler.

As for changing export info, it doesn't work correctly now, but I think it can be fixed:

So, I'm not sure about this feature yet, but I decided to check it out to see how feasible it is.

[Mickeon]

You cannot change the variable type.

Good, but in practice it would still be desirable to narrow it down with covariance like in #82477

That is, the variable will be assigned twice (or more, as many overrides). In all initializations the setter will not be called, since there is an exception for the initializer. I'm not sure if this is a good thing, but I don't see how we could implement it without complicating the compiler.

This may actually not be too much of a deal-breaker for most, but it is certainly a waste of processing time which would be nice to avoid.

[hmturnbull]

• You cannot change or remove setter/getter because GDScript is a fairly dynamic language and it would be weird to have different behavior depending on the type and casts inferred by the analyzer.

👍

Since you can override the content of the setter/getter function like any other function, changing the variable so it points to a different setter/getter entirely would be completely pointless and make everything needlessly confusing.

How messed up would it be if you called a setter function in code, only to find out it wasn't the correct setter in the specific object you were dealing with? 🥶

[Laskivi]

Just chiming in to say this is an absolutely necessary feature for using inheritance with Resources and RefCounteds. Especially RefCounteds, since they cannot be exported to the inspector. I was going about my business making abstract Resource classes in my project, expecting being able to easily override their variables to be completely par for the course. I was very happy to find that abstract classes and methods will be added in 4.5, but a bit surprised that overriding parent variables wouldn’t also be part of the package just yet. These things go hand in hand. Would really appreciate this!

[FoxyFox909]

Just chiming in to say this is an absolutely necessary feature for using inheritance with Resources and RefCounteds. Especially RefCounteds, since they cannot be exported to the inspector. I was going about my business making abstract Resource classes in my project, expecting being able to easily override their variables to be completely par for the course. I was very happy to find that abstract classes and methods will be added in 4.5, but a bit surprised that overriding parent variables wouldn’t also be part of the package just yet. These things go hand in hand. Would really appreciate this!

Yeah, the only workaround is using _init method on the extended script, but that is cumbersome