Godot: Default functions are called in super classes - override mechanism inconcistency in GDSript

[ripperdave]

I could see a recurring issue that cause confusion amon users and inconsistency in GDScript. I propose to create a roadmap to handle and fix the issue and also backward compatible with old projects.

Calling default functions in super class should happen manually by using ._()

From docs:
"Remember that default functions like _init, and most notifications such as _enter_tree, _exit_tree, _process, _physics_process, etc. are called in all base classes automatically. So there is only a need to call the function explicitly when overloading them in some way."

It was a bad strategic decisions for default functions. It is against override mechanism. It forces hacking.
For example: I had to introduce ignore boolean flags and condition checks to _input(event) methods in super classes.

Godot is getting mature. GDScript should do the same.
Thinking about backward compatibility:
[Proposal]
What about a compiler/editor settings that could change that to industry standard behavior?
The release note could clarify this so old project could work too. Maybe it could be fixed in higher release like 4.0.

Story behind this issue:
From Reduz:
"callbacks get called at all levels, back when we had Squirrel programmers
used to forget calling the parent functions all the time for callbacks they
handled different and it was kind of a mess. "

Reply: beginner users won't use heavy inheritance at the beginning. Advanced users and heavy project would use it. Heavy projects would require programming skills anyway.

Recurring issue with good points in it read them:
https://github.com/godotengine/godot/issues/20349
https://github.com/godotengine/godot/issues/6500
https://github.com/godotengine/godot/issues/23286

[regakakobigman]

I agree. The current system makes it slightly easier to call overrided methods, at the cost of making it more difficult to _not_ call them. Calling an overrided method is always simple and easy; not calling one should also be easy, but isn't.

[TheDuriel]

Not only is this behavior currently inconsistent, but also makes proper use of inheritance much more difficult than it should be. The fact that you can not properly override _ready or _process when extending a class that already defines them is very silly.

[groud]

I strongly disagree. I think the current behavior is the best possible solution for the problem. It makes it easy for everyone to execute something without worrying about whether or not you are overridding something or not, and thus stays really easy for beginner. Also, this is the most common use case, calling the parent function there all the time would be a pain for everyone.

If you need an overridable behavior, simply define your own my_process() function, call it in the parent class and override it if you want. It is a simple workaround that can be used when you really need an overridable behavior (which is rarely the case)

Having two possibilities is a bad idea too, there is no such crazy thing as a "depends on an option language". That would make creating tutorials a lot harder.

[EngBraga]

@groud , one problem i have found is that _ready() executes on the parent first, but _process and _physics_process() executes on the child first. It's kind of confusing for a begginer like me.
Is this too an intended behaviour, @reduz ?

[groud]

Yes, it due to how things are processed in Godot.
If it is not already, it should be documented.

Regarding the initial problem, I think someone (in an issue I cannot find) suggested to mention a dedicated function type the documentation. Something stating that a function is in fact a notification, and thus cannot be overridden.

[ripperdave]

One comment to the settings dependent behavior:
Java has options to compile sources to different versions like 1.4 or 1.8. Godot could have 3.1 or 4.0. It solves the worries about backward compatibility and removes the burden of old limitations. I understand that it generates complexity and also would create hard time in git.
Such a solution works in the industry.

[char0xff]

There is not really much else to discuss about, it just needs to be implemented.

[Wavesonics]

I found this very confusing coming from other more traditional languages. Besides breaking normal OO convention, it makes some things quite difficult to do! All that to say, I'd fully support this even knowing it'd be a breaking change.

[creeperdeking]

Actually I believe it will be better for beginners too, as now it will be clear to them who call what when. I mean come on, gdscript is the only language that does that kind of stuff.

[Calinou]

@creeperdeking Not that I'm against changing this, but keep in mind this will break most tutorials out there. Are you prepared to deal with the flood of support requests? :wink:

[TheDuriel]

I don't think there are many tutorials that deal with inheritance at all, much less so with function overriding. So I'm still in favor of someone implementing this.

[Jummit]

will break most tutorials

I don't think most of Godot tutorials use this.

[Frontrider]

I just hit this issue, because I wanted to be sure that my super method is called. That is how unintuitive this method is. I see the reason, adds some security, but it still looks icky.

[Calinou]

Closing in favor of https://github.com/godotengine/godot-proposals/issues/594, as feature proposals are now tracked in the Godot proposals repository.

[Zireael07]

Yyy, closing in favor of itself? :/

[Calinou]

@Zireael07 Fixed :slightly_smiling_face: