calling super class method which has a different name

Hello,

i am wondering that a derived class cannot call all methods from the super class. It is restricted to the same name!

Are there plans to change this in near future? Whats the sense of this restriction? Is there a possibility to avoid it?

Answer 1

[Daniel Shub]

Are there plans to change this in near future?

Only an employee of TMW can tell you that.

Assume:

1. A class hierarchy of subsubclass < subclass < superclass.
2. superclass defines a method methodA
3. subsubclass overloads methodA
4. subclass defines a method methodB

The overloaded methodA can call the non-overloaded superclass methodA by methodA@superclass( ... ). This allows you to easily extend methods. It sounds like you want to make methodB call the non-overloaded methodA by doing methodA@superclass instead of the overloaded methodA, which is simply called by methodA( ... ). I think this is a bad idea. There is probably a reason the subsubclass overloaded methodA and you are bypassing it. Do you have an example where bypassing the overloaded method is helpful?

Answer 2

[wma]

Hello Daniel, thank you for the quick response.

Specialisations are not the only reason why to call the super class. Super classes can offer the most general functions for the subclasses so it is not a bad idea to call super class methods. In c++ this is a common way to avoid dublicated code or merging different logical behavior in same methods.

For example i have an algorithm hierarchy

Level3 < Level2 < Level1

In Level3 i have the most flexible algorithm which can use Level1 to estimate the initial values.

So i have a method adjust in Level3 which calls estimate in Level3 first. Estimate needs to call adjust@L1 but this does not work:

% Level3 Method to adjust the parameters
function hObj = adjust(hObj)

% Estimate initial values with L1
hObj.estimate();

end

% Level3 Method to estimate parameters
function hObj = estimate(hObj)

% Prepare data
...

% Estimate initial values with L1 (does not work)
hObj.adjust@L1();

end

I know there is a way to avoid this and i have already done it but it is not as elegant as the upper code.