Repository: godot
Issue: Extending engine classes in GDScript or C# not working
Labels: topic:gdscript,documentation,topic:dotnet

**Godot version:**
3.2.1

**OS/device including version:**
All platforms

**Issue description:**
Extending engine classes is essentially broken.

**No control over call of super functions**
In the current state, godot will call all the super classes' implementations of a function and the user has no way to opt out of that behavior, [as discussed in this issue](https://github.com/godotengine/godot/issues/6500). I completely understand [the reasoning](https://github.com/godotengine/godot/issues/6500#issuecomment-247370255) for this behavior and agree on that. While for user-written classes, there is a workaround:

```
# override this in your subclass
func _on_process(delta):
    pass

func _process(delta):
    _on_process(delta)
```
**The problem** is, _we cannot apply this workaround on engine classes_. As a result, extending engine classes in GDScript is barely supported in the moment, as it is not possible to override functions of engine classes properly.

Another problem is that some functions work like this, and _others don't_. There is a lack of consistency.

I thought quite a bit about it, and from the various options available, I think introducing the new keyword `override` might be the best option:
```
override func _process(delta):
  if we_want:
    ._process(delta)
```

So essentially, `override` will prevent the super classes' implementations of this function to be called. The user opts-in to that behavior and is then in full control if/when/how the super method is called. The "[squirrel programmer](https://github.com/godotengine/godot/issues/6500#issuecomment-247370255)" is still fine and everybody else used to OOP got his powers back.

More as a site note: the second reason why extending engine classes is essentially broken in godot in the moment is that it is impossible to extend _virtual_ engine classes and provide a GDScript-implementation of these interfaces. This is [discussed here](https://github.com/godotengine/godot/issues/38294) and [here](https://github.com/godotengine/godot-docs/issues/3460), and affects _all virtual engine classes_ exposed to GDScript.

**How to fix**
In an ideal world, I would love to have the `override` keyword and have full control on extending engine classes. Also, I would like to be able to implement virtual engine classes. Naturally, this would increase flexibility of GDScript a lot [as discussed here](https://github.com/godotengine/godot/issues/38294). This would essentially fix inheritance of engine classes in godot.

If this is not possible for technical reasons, we should at least add a warning/errors to save the user from some frustration:

- a warning when a user tries to extend an engine class, because what he is trying to do might in fact not work out at all, because he will have no control over if and when super functions are called.
- an error when the user tries to extend virtual engine classes, because this is in fact not working at all
- a warning when the user tries to call super functions like `._process` or `._ready`, because this would call the super method twice, and this is most likely _not_ intended

Thank you guys for your great work on this wonderful engine. I think it's normal there are flaws at some point, but it's important to save the user from endless frustrating hours trying figure out what's going wrong.

Thank you for considering, I appreciate your thoughts about this.