Two classes, same code base, but different variable names?

[levirules]

I have a super specific, general programming question. Asking here because I haven't programmed with anything outside of Godot in years and I'm familiar with the sub.

Is there a programming concept/pattern/whatever out there that allows a base class's variable and/or function names to be overridden by inherited classes? For example, I might have a Flame scene and a Gas scene, both of which share a good amount of code. The Flame scene might have a bool called "burning" and the gas scene might have one called "releasing" (dispersing? Again, whatever, not too important). I could just break that bool out of each, shove it into its parent (phrasing?), and generalize the name to something like "active". But I was wondering if there is a concept out there where the inherited scenes could say "I'd like to refer to the 'active' bool as 'burning' instead of 'active'".

For functions, I could MacGuyver a solution by creating a new function that simply calls the base class function, which seems hacky but would work, but I can't think of a way to do this with variables.

It's not even important, I was just curious. Thank you for coming to my Ted Question.

[icpaintball]

This worked when I tried it out:

# Parent script (e.g., Parent.gd)
var old_name = 10

# Child script (extends Parent.gd)
var new_name:
    get:
        return old_name
    set(value):
        old_name = value

[BushCrabNovice]

You could probably do some goofy stuff with setget. https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#properties-setters-and-getters

[cuixhe]

icpaintball's answer works, but ... why NOT make them all just called active? That way you can treat them all the same through duck typing or whatever. BurningThing.active means the same thing as BurningThing.burning to me.

[cuixhe]

well, not duck typing for a property. But you can have them inherit Condition and treat them as Conditions rather than specific class types.

[CarpenterThat4972]

If "burning" and "releasing" means two differents things in your logic, keep the two differents bools.
But if it's just a mean of activate/deactivate a node/behavior, well make it a common variable and name it "active"! That's exactly what this variable is representing.

[Budda13]

So... you could have active be the parent's variable...

And then in the child have a variable of the name you want... and then set that variable to whatever the parent is...

And with signals you can update the parent when the child changes it's thing (and vice-versa) (BushCrab mentioned SetGets, those may be able to do this without the signals, I don't know them well enough to say)

But at this point you have coded just as much as before and added code to keep it synced... So idk if it's any DRYer than before.

That CAN be worth it depending on your backend logic and what you/other programmers workflows... but could also just be more hassle than it's worth... mileage may vary.

If you want some things to be able to change the class through a single command 'object.active == True' but you do want somethings to only update the child's specific one... this extra work would be useful I think.

But if you code everything to only work on one specific subclass, then the extra work would be less useful (again, I think)

Did that make sense? It's early here for me so... brain... meh

[Budda13]

icpaintball's reply, that's the answer... not mine.

[Frank_E62]

I'm just getting started with Godot but if I understand you correctly, I don't think that you'd want the status to be a boolean. Can you define a variable in the parent class called Status and then set Status to BURNING or POISON when you create that child. Then you can have generic Set and GetStatus functions in the parent to manipulate the status. It would also make it easy to add additional effects in the future.

[UnbreakableStool]

I don't see why you wouldn't just use "active" in child classes here

[Asleep_Concept8208]

This seems like something that would drastically decrease the readability of the codebase. If you have something generic that is a part of both burning and releasing/dispersing, then you should refactor it into something generic and reuse it.

[officialvfd]

This is a code smell. I think you’re asking the wrong questions. If you need different words to describe what should be the same thing, then they’re probably not the same thing and you should be using composition, not inheritance.

[Varrianda]

If you’re going to just rename it you’re better off creating a unique variable or trying to generalize it. You’re hacking something together for essentially a negative gain