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

Reply via email to