www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Method overloading and inheritance

reply 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.
Jul 03 2009
next sibling parent "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
Jul 06 2009
prev sibling next sibling parent 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.
Jul 06 2009
prev sibling parent "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
Jul 07 2009