Skip a generation in a base call in an override function?

Unity Engine
1

Is it possible to skip a generation when I make an override call?

So if have have:

class Granddaddy : MonoBehaviour
{
protected virtual void foo()
{
}
}

class Daddy : Granddaddy
{
protected override void foo()
{
base.foo()
}
}

class Childy : Daddy
{
protected override void foo()
{
base.foo()
}
}

…But I want the function in Childy to call the original root function in Granddaddy, not the one in Daddy.
Is there a way to do this in Unity?

I was doing a search for how to do it in C#, and I got a lot of results saying it was impossible. But these were rather stupid responses of people saying that the grandchild class should just be directly extended from the original grandfather class. Yeah, maybe that kind of practice works when you’re making a new spreadsheet viewer, but when you’re programming something as complicated as a video game, that’s an absurd demand to make.
The inherited code exists within the class; that’s bad design on the language if it’s not possible to call routines that exist within the class.

So has the scripting within Unity enabled a way to get around this shortcoming? Is there a way for me to skip a generation in my script?

2

EDIT: Disregard post… I guess base.base isn’t a thing. :slight_smile:

3

c# - How to call base.base.method()? - Stack Overflow this person provided a solution, although at the same time mentions it is bad practice.

4

I could never disregard your posts, Kurt! Your advice has been too valuable to me!

5

Well gosh, thanks! Nice to hear that.

When I first wrote the post above I kinda thought “yeah, doing base.base.foo() would not be a good thing,” kinda like the post that Rad Red Panda posted above.

But on second thought, if that worked, eh, just do it already, get your problem solved, move tf on already.

Here’s another tool that might help you too, instead of multiple layers of inheritance: interfaces.

And here is how interfaces are extremely cool in Unity, basically first class citizens alongside MonoBehaviours:

Using Interfaces in Unity3D:

https://discussions.unity.com/t/797745/2

https://discussions.unity.com/t/807699/2

Check Youtube for other tutorials about interfaces and working in Unity3D. It’s a pretty powerful combination.

6

I could have sworn that it was possible to call base of a higher (lower?) class. But I think I was just remembering doing it in UnrealScript.

Man, I miss UnrealScript; that was a language designed for making games. In all honesty it’s disappointing that C# wasn’t designed with some of its features.
You could create states in a class, which let you use the properties of inheritance within a single class and change them at run-time. Like, a player movement function could use a different version if the player was on ground, in the air, or in water. Sure you can create variables to check and then call different functions, but that was so much cleaner!
And then you can set up default variable values for different classes, so if you extended a class the child could just change the default/starting values for variables you inherited from the parent class.
I mean… I guess it’s all functionality you can still create, but it was so nice to have it all conveniently built-in. So wish that they had put in stuff like that into C#.

Oh well.
/reminiscing.

7

You can basically do just about everything you did in UnrealScript but it’s just done in a compiler-safe way.

For instance what you describe above is just delegates / System.Action / System.Func variables.

The main reason you wouldn’t want base.base.foo() is because it means Childy has to know there are two generations above him, whereas his declaration only says his immediate Parent. What if in the future someone refactored Parent to not have a Grandparent? Every Childy would magically break if they reached up to the Grandparent.

8

I can’t fathom that not having massive repercussions on all the child classes anyway.

I make changes to a parent class and find some random child class gets borked up without anyone telling me ALL THE DANG TIME. I can’t imagine overhauling a parent class to not extend from a grandparent class not borking things up even worse.
Honestly I would expect that it would at least cause an easily-tracked compile error since it is trying to reference a base class that no longer “exists.”

But that’s just me, and my code is held together by duct tape and the tears of my CPU.