View mode: basic / threaded / horizontal-split · Log in · Help
July 04, 2009
Method overloading and inheritance
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
Re: Method overloading and inheritance
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
Re: Method overloading and inheritance
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
Re: Method overloading and inheritance
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
Top | Discussion index | About this forum | D home