Thread overview
Method overloading and inheritance
Jul 04, 2009
Mike L.
July 04, 2009
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.
July 06, 2009
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
July 06, 2009
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.
July 07, 2009
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