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

[Jacob Carlborg]

On 2011-05-25 08:02, Ali Çehreli wrote:
> 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.

Yes, but all declarations in classes or modules are public by default.

>  > 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.

I don't where you get the private from (assuming he's talking about 
http://digitalmars.com/d/2.0/function.html#function-inheritance).

>  > 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
>


-- 
/Jacob Carlborg