What is the design reasons for Not considering base class overloaded function?

Ali Çehreli acehreli at yahoo.com
Tue May 24 23:02:16 PDT 2011


On 05/24/2011 10:28 PM, Matthew Ong wrote:

 > However, when doing overload resolution, the functions in the base class
 > are not considered:
 > ....
 > // ### Why Not? Since B is a subset of A, and within B itself methods
 > inherited from A can be called.
 > b.foo(1); // calls B.foo(long), since A.foo(int) not considered

That is to prevent silently changing the program's behavior. b.foo(1) 
could happily be a call to B.foo(long) today. Imagine one of the base 
classes changed and now there is A.foo(int). Then our b.foo(1) would 
silently start calling that new function. That would cause a tough bug.

 > What is the default encapsulations of a class functions?
 > (public/private/package...)

private. In D, the entire module has access to private members.

 > I assume that the example shown here are public because they are used in
 > function bar?

No. As bar is in the same module, it has access to private members.

 > How about when the inheritance tree becomes deeper than 4? And more and
 > more overloaded functions are in different classes? Does it mean we have
 > to do more alias at child class at the bottom?

I don't think this issue is common. Here, the decision is the safer one. 
Only when we know what we're doing, we can change this behavior.

 > If I am not mistaken, in C++/Java. They will choose the most bottom up
 > closes parameter type signature match.

Not in C++. C++ has "name hiding", which hides all of base's functions 
and members with the same name.

Ali



More information about the Digitalmars-d-learn mailing list