Calling super.super base method

BlitzMax Forums/BlitzMax Programming/Calling super.super base method

col(Posted 2015) [#1]
Hmm,

I'm not sure how come I've not come across this before, or maybe I just can't remember if its possible or not ( been using a lot of c++ lately ), but is there an easy cast of some sort for me to call the base method of a base method from the derived one?

Eg


I feel super.super should work, although I understand why it doesnt. Or maybe at least an explicit cast. I did a search of super.super and there are only 3 results including this one. The other 2 are necro, I thought this issue might have been handled by now?

Edited because of terrible typos :D


Yasha(Posted 2015) [#2]
I'm going to voice the unpopular opinion here and say that if this is a real obstacle, it indicates a serious code smell in your class hierarchy. If you don't want the functionality of DerivedBase, why are you extending it? This sounds like a violation of LSP waiting to happen.

The "best" fix is likely to involve removing the implementation of either DerivedBase.CallMe or Base.CallMe from the inheritance chain and supplying that method in a delegate instead.

I'm guessing the issue wasn't solved because in practice deep inheritance chains are an antipattern that BlitzMax doesn't need to encourage (even needing two implementation layers is pretty rare), and you can always implement the design with composition instead - you don't even need a third class; as a quick workaround, you could even give Derived a private instance of Base to forward to.


col(Posted 2015) [#3]
Hey,

Its not obstacle at all as I can, and did originally, easily duplicate the 2 pieces of data in the derivedbase. I was just trying to break things up a little too much and be too 'smart' :/

For info...
I did want the functionality of the derivedbase and the base methods as proposed in the first post, however I realised after posting that the method was being used for its correct purpose but at different times of processing... ultimately it was inappropriate to do this and should of had a separate method for its 2nd use case or just as easily keep the duplicate fields in the derived.

Thanks for the links. They could be useful for others too.