In the following test case, Base.foo(int) is not inherited by Derived.  This is also the case in C++, but I wonder whether it is desirable behavior, and if so, why?  I find it counterintuitive.

------------

private import std.stdio;

abstract class Base {
    final void   foo(int i)   { writefln("i = %d", i); }
          void   foo(float f);
          char[] toString()   { return "Base"; }
}

class Derived : public Base {
    void   foo(float f) { writefln("f = %f", f); }
    char[] toString()   { return "Derived"; }
}

void main() {
    int   i = 2;
    float f = 2.5;

    Derived d = new Derived;
    d.foo(i); // f = 2.000000
    d.foo(f); // f = 2.500000

    Base b = d;
    b.foo(i); // i = 2
    b.foo(f); // f = 2.500000
}


------------

Regards,
Garett

Garett Bass wrote:

[...]
> I find it counterintuitive.

According to the rule that non integers are not converted implicitely to integers this must be a bug, because there is no explicit conversion.

-manfred

On Thu, 24 Nov 2005 11:49:52 -0600, Garett Bass <garettbass@studiotekne.com> wrote:
> In the following test case, Base.foo(int) is not inherited by Derived.  This is also the case in C++, but I wonder whether it is
> desirable behavior, and if so, why?  I find it counterintuitive.

There are already a few threads on this, have a search you'll see what I mean. (I cant think of a good search term, sorry). D follows C++ and Java does it differently, how you we're expecting I imagine.

Regan

On Thu, 24 Nov 2005 18:57:47 +0000 (UTC), Manfred Nowak <svv1999@hotmail.com> wrote:
> Garett Bass wrote:
>
> [...]
>> I find it counterintuitive.
>
> According to the rule that non integers are not converted implicitely
> to integers this must be a bug, because there is no explicit
> conversion.

I don't see a non-integer -> integer conversion?

I only see a integer -> float conversion, here:
    int i = 2;
    ...
    Derived d = new Derived;
    d.foo(i); // f = 2.000000

Regan

Regan Heath wrote:

[...]
> I don't see a non-integer -> integer conversion?
[...]

Woohoo. Me too. The usual error in case one is in a hurry: the stated rule is true, but the assumption that there are any consequences if applied to the concrete case at least untrue.

Begging for a pardon for a post witnessing of a mind sometimes some hours behind the appropriate starting point :-)

-manfred

On Thu, 24 Nov 2005 22:42:02 +0000 (UTC), Manfred Nowak <svv1999@hotmail.com> wrote:
> Regan Heath wrote:
>
> [...]
>> I don't see a non-integer -> integer conversion?
> [...]
>
> Woohoo. Me too. The usual error in case one is in a hurry: the stated
> rule is true, but the assumption that there are any consequences if
> applied to the concrete case at least untrue.
>
> Begging for a pardon for a post witnessing of a mind sometimes some
> hours behind the appropriate starting point :-)

No worries. I assumed one of us simply made a mistake.
Regan

In article <ops0rjgvj923k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Thu, 24 Nov 2005 11:49:52 -0600, Garett Bass <garettbass@studiotekne.com> wrote:
>> In the following test case, Base.foo(int) is not inherited by Derived.
>> This is also the case in C++, but I wonder whether it is
>> desirable behavior, and if so, why?  I find it counterintuitive.
>
>There are already a few threads on this, have a search you'll see what I mean. (I cant think of a good search term, sorry). D follows C++ and Java does it differently, how you we're expecting I imagine.

I think "alias" is a good search term. (Or try "antialias" ;-) You solve it by adding the line "alias Base.foo foo;" to Derived.

I found it counterintuitive at first too (in C++), but when someone here (Walter I think) explained the reasoning behind it, I found I actually agree with it. In a complex class hierarchy, it is sometimes hard to keep track of every member defined in all parent classes. If it didn't work the way it does now, you might by accident end up calling a function that you forgot about or didn't even know existed, defined in some base class.

Nick

Nick,

    Thanks for the tip.  I find this solution acceptable.

Regards,
Garett


> I think "alias" is a good search term. (Or try "antialias" ;-) You solve it by adding the line "alias Base.foo foo;" to Derived.
>
> I found it counterintuitive at first too (in C++), but when someone here (Walter I think) explained the reasoning behind it, I found I actually agree with it. In a complex class hierarchy, it is sometimes hard to keep track of every member defined in all parent classes. If it didn't work the way it does now, you might by accident end up calling a function that you forgot about or didn't even know existed, defined in some base class.
>
> Nick