• Mike L. (1/1) Jul 03 2009 So currently if you want to overload just one case of an overloaded func...
• Steven Schveighoffer (17/27) Jul 06 2009 It has to do with hijacking.
• Jarrett Billingsley (2/5) Jul 06 2009 It's particularly annoying, though, that there is no way to do this for ...
• Steven Schveighoffer (24/31) Jul 07 2009 AFAIK, there's no way to do that in Java either. What's unique about

Mike L. <sgtmuffles myrealbox.com> writes:

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.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 03 Jul 2009 21:36:01 -0400, Mike L. <sgtmuffles 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

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Jul 6, 2009 at 3:12 PM, Steven Schveighoffer<schveiguy yahoo.com> wrote:
 In addition, the workaround to get the desired
 behavior is pretty straightforward (the alias base.function function
 syntax).

It's particularly annoying, though, that there is no way to do this for ctors.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Mon, 06 Jul 2009 15:54:29 -0400, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:

 On Mon, Jul 6, 2009 at 3:12 PM, Steven  
 Schveighoffer<schveiguy yahoo.com> wrote:
 In addition, the workaround to get the desired
 behavior is pretty straightforward (the alias base.function function
 syntax).

 It's particularly annoying, though, that there is no way to do this for  
 ctors.

AFAIK, there's no way to do that in Java either.  What's unique about  
constructors is that you can't access the base constructors *except* from  
another constructor.  A member, however is accessible, even if it is  
hidden.  For example, this workaround makes it somewhat foolish:

class C
{
   void foo(int a);
}

class D : C
{
   void foo(string s);
}

auto d = new D;
d.foo(1); // compile error
C c = d;
c.foo(1); // ok. or sometimes a runtime error (ugh!)

Just by simple retyping (no casting), you can access the base members.   
constructors are different though.  What you really want is to say that  
the derived class does not redefine construction, or only modifies it.  I  
think actually, allowing base constructors might be an easier thing to  
implement in the spec/compiler, because no vtables are involved.

-Steve