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