Method overloading and inheritance

[Steven Schveighoffer]

On Fri, 03 Jul 2009 21:36:01 -0400, Mike L. <sgtmuffles at myrealbox.com>  
wrote:

> So currently if you want to overload just one case of an overloaded  
> function, you have to use an alias for the class to keep the behavior of  
> the other cases. I talked about it a little in #d, and the only reason  
> that was given was that it might protect the programmer somehow. But why  
> should the default behavior cause a sub-classto no longer behave like  
> the class that it extends? Not to sound like a Java fanboy (I'm not,  
> it's just the only other language I'm able try it out on right now), but  
> it doesn't require anything like that, and behaves how I would consider  
> intuitively. Isn't function overloading just re-using a name? Why is  
> that reason to treat things differently when they're inherited? Thanks.

It has to do with hijacking.

Read http://www.digitalmars.com/d/2.0/hijack.html

The pertinent part is in the sections entitled "Derived Class Member  
Function Hijacking" and "Base Class Member Function Hijacking"

I argued your case, oh like 2 years ago, but Walter believes that  
Hijacking is too much of a risk to allow overriding a single overload  
without overriding all of them.  In addition, the workaround to get the  
desired behavior is pretty straightforward (the alias base.function  
function syntax).

Note that C++ rules are the same as D's.  I think in actuality, Walter  
just implemented the C++ rules, and then came up with the hijacking  
reasoning afterwards to explain why he did it ;)  I have to admit, in  
practice it doesn't come up very often unless you have certain designs.   
For instance, I used C++ for many years, and never ran into this problem.

-Steve