On Tue, 30 Aug 2011 07:04:27 -0400, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
On Tuesday, August 30, 2011 06:47:03 Steven Schveighoffer wrote:
On Mon, 29 Aug 2011 16:24:46 -0400, Jonathan M Davis
<jmdavisp...@gmx.com>
wrote:
> On Monday, August 29, 2011 14:09 Mariusz Gliwiński wrote:
>> <code>
>> interface Interface {
>> Interface method();
>> }
>> class Class : Interface {
>> override Class method() {}
>> }
>> </code>
>>
>> DMD complains it isn't overriding. How should it be according to
>> specification, and how about making it legal?
>
> It's _not_ overriding. It's implementing an interface method. Those
are
> two
> totally different things. And I think that it's horrible that Java
> considers
> implementing an interface method as overriding it. I'd _hate_ to see
> that in
> D.
Then this must be a bug?
interface I
{
void foo();
}
class C : I
{
override void foo(); // compiles
}
I feel override should be *allowed* when implementing interface
functions
(but not required). Otherwise, you get into situations where a base
class
decides to become abstract (doesn't implement a function), but a derived
class is specifying override (especially if override is required, as is
planned), if that's a compiler error, I think it's a useless error.
I think that override belongs on functions which actually override base
class
functions. It should be required when a function overrides a base class
function, and it should be disallowed when it's on a function that
doesn't
override a base class function. Interfaces have nothing to do with it.
The whole point of override is to make sure that you know when your
function
is or isn't overriding a base class function. Ff the base class changes,
then
that's extremely relevant to the derived class, and it _should_ error
out if
the function is no longer marked as it should be (be it that it has
override
when it shouldn't or that it doesn't have it when it should). That way,
you
never have functions which override when you didn't mean them to (e.g.
if a
new function were added to one of its base classes), and you never have a
function which _doesn't_ override when you mean it to (e.g. when a
function
was removed from one or more of its base classes).
This argument has holes in it:
class A
{
void foo();
}
class B : A
{
version(newlyAddedBFoo)
override void foo();
}
class C : B
{
override void foo(); // does not see newly added B.foo
}
This will compile fine with or without the version enabled. When you say
override, you say "I don't care what came before me, I'm implementing this
function." Now, if B decided to make foo final, yeah, you should know
about it. But I don't see why override shouldn't simply work when
overriding a not-yet-implemented function.
What about an abstract base method, should override be required?
class A
{
void foo() {}
abstract void foo2();
}
class B : A
{
override void foo() {}
override void foo2() {} // should override be rejected here? What
utility would an error give you?
}
At the end of the day, an interface is simply a completely abstract
class. It might even have some implementation via final or template
functions, but it participates in virtual functions much the same way as
classes do.
-Steve
