Proposition for change in D regarding Inheriting overloaded methods
Regan Heath
regan at netmail.co.nz
Tue Aug 7 10:49:50 PDT 2007
Steven Schveighoffer wrote:
> So my proposal is to change the specification so that:
>
> If there is a class A, which is a base class of class B, where A defines a
> method foo(args), and B defines a method foo(args2), such that the types of
> args2 cannot be implicitly converted to args, and B does not define
> foo(args), then the definition of B.foo(args) shall be implicitly aliased to
> A.foo(args). If, using the same assumptions, args2 can be implicitly
> converted to args, then the compiler should fail to compile B indicating
> that the user must define B.foo(args) by override or by alias.
>
> I believe this will give us the best of both camps, and allow much less code
> to be released with silent bugs than the current implementation.
>
> Let the hole shooting begin...
I like it. In fact it solves the existing problem exhibited by the
original example 2!
Here are our original examples given by Walter and used to support the
current C++ like behaviour.
-----------------------------------
class X1 { void f(int); }
// chain of derivations X(n) : X(n-1)
class X9: X8 { void f(double); }
void g(X9 p)
{
p.f(1); // X1.f or X9.f ?
}
-----------------------------------
class B
{ long x;
void set(long i) { x = i; }
void set(int i) { x = i; }
long squareIt() { return x * x; }
}
class D : B
{
long square;
void set(long i) { B.set(i); square = x * x; }
long squareIt() { return square; }
}
long foo(B b)
{
b.set(3);
return b.squareIt();
}
-----------------------------------
Under your proposal these would both be classify as "incorrectly
implemented override"'s and fail to compile with an error.
In example 1 the error would occur when compiling X9. In example 2 the
error would occur when compiling D. In both cases the addition of
'alias' or an exact override for the 'int' method from the base will
resolve the error.
In example 1, if other overloads existed in X2 thru X8 i.e. "void
f(short);" then both "void f(int);" and "void f(short);" would need to
be aliased or defined in X9 to resolve the error. This seems to
indicate that all base classes all the way back to the root need to be
examined, that could be complex...
As I mentioned earlier your proposal will solve the existing problem
caused by example 2, which under both C++ and Java like implementations
calls B.set(int) then D.squareit() resulting in 0 instead of 9.
That, combined with the implicit alias of overloads where no implicit
conversion is possible and I think it will be a feature which is both
safe and intuitive.
I'm interested to see what other people think.
Regan
More information about the Digitalmars-d
mailing list