-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow child class to override parent constant #24879
Comments
Seems like |
Well, if a constant can see its value modified by children it is not a constant anymore. So IMHO, what you propose is quite a bad practice in general, as it creates several versions of a constant with differents values (which is the opposite of a constant) . |
Indeed, as mentioned by @isaacremnant you should use |
There is a need for this Usecase: class Vehicle class Bus extends Vehicle class Bike extends Vehicle When we want to check how many wheels a bike has, we won't need to create a new Bike instance to check this. Reopen issue please? |
@CptTony303 Feature proposals should now be discussed in the Godot proposals repository. But first, keep in mind:
|
In your specific use case, static access, there is no need for the Vehicle parent? Unless I misunderstand a particular way to access static variables, you'd never refer to Vehicles generically -- you'd always explicitly write 'Bike.wheels'. So, you can safely just exclude 'const wheels = null' from class Vehicle. |
It should still be treated as a run-time constant, which is the important part. I agree with @CptTony303 and feel that their example very clearly outlines the usefulness of a feature such as this. |
I just ran headfirst into this limitation. I'm trying to make a dictionary that holds all the monster scenes - This should make creating/editing random encounter tables much easier. A key has to be a constant, which means that my monster template scene can't define or even declare this necessary piece of data. It also means that I can't have upgraded monsters (common example: early game has regular spiders, late game has fiendish spiders) inherit from the original or base version of the monster, because then they'd share the same dictionary key. I guess it's either back to the drawing board, or just bite the bullet and do it the annoying (read:less maintainable) way. |
I second this feature. Here is an explanation of why this doesn't violate good practices for constants:
That would indeed be a problem. But that isn't what happens; the parent class is not modified. Its const value remains unchanged. No values are changing during runtime for either class. Everything remains constant. Hence, no issues will be caused in multi-threading etc. This feature is just a major labor saving device. Consider this: You could manually type out two classes, a "Bike" class and a "Truck" class, and you could fill them with 90% of the same code, save a few differing const values. Everything remains constant, and the program runs fine. But, if this feature existed, then you could save yourself all that trouble, write one Vehicle class, and inherit from it twice, with a few const overrides and function overrides. This has an identical effect as writing two classes from scratch, but saves you a lot of work and ugly code duplication (which itself is a bad practice). Without this feature, you can still approximate this as is, by creating a function called "get_num_wheels()" and override it for Bike and Truck respectively. Of course, then a function has to be called every time to get the value, which is unnecessary overhead, because the value never changes. Hence, since it doesn't change, is shared between all instance of a class, and doesn't need to be calculated, it should be stored in a const, and not a var, nor a function. Peace. |
i have the same problem. im using static function instead class A:
# const a = 1
static func a():
return 1
class B extends A:
# const a = 2
static func a():
return 2 sorry for that im not familiar with dynamic typed language, in my view, a so it looks weird for me. since static function can be overwrited but |
I propose gdscript should allow for a child class to override constants declared in the parent class. It seems like a very common use case for a child class to inherit all the same functionality of the parent, but with differing parameters to provide differing behaviors. As it is currently, a class becomes unextendable with the declaration of a constant whose value is not suitable for every single potential child. A trivial example:
Without this functionality, it seems one is forced to use a non-constant value instead, setting the child class' value in the
_init()
method, even if you never intend to change SPEED at runtime.The text was updated successfully, but these errors were encountered: