[Issue 16318] inherit from interface via abstract class

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Fri Aug 12 07:28:20 PDT 2016


https://issues.dlang.org/show_bug.cgi?id=16318

--- Comment #4 from Lodovico Giaretta <lodovico at giaretart.net> ---
(In reply to b2.temp from comment #3)
> (In reply to Lodovico Giaretta from comment #2)
> > If I inherit directly from an interface, I can override:
> > 
> > ==================
> > interface IFoo { void foo(); }
> > 
> > class FooImpl: IFoo { override void foo(); } // override here is fine
> 
> I suspect this usage of "override" of being an noop.
> We need an exact analysis from a DMD expert here.

If what you say is correct, that is very bad. It gives a wrong idea of what
override does really mean. See my next comment.

> > It seems counterintuitive that you can't do this transitively:
> > 
> > ==================
> > interface IFoo { void foo(); }
> > 
> > abstract class AFoo: IFoo {}
> > 
> > class FooImpl: AFoo { override void foo(); } // override here does not work
> > ==================
> > 
> > It is true that it works if I remove "override", but this makes it unclear
> > that FooImpl.foo overrides IFoo.foo. 
> 
> FooImpl.foo doesn't **override** IFoo.foo, it **implements** IFOO.foo.
> 
> The compiler will throw an error if you forget. Here you argument is really
> a matter of taste. I can say that what makes unclear that IFOO is
> implemented because an abstract class is used in the middle.

Ok, I gave override a different meaning. I can accept this, but then IMO we
need a way to say "this methods implements an interface method". It is at least
as useful as "this method overrides another method", so much that I (and
probably many other programmers) conflate the two meanings into one "this
method is part of another API, not a specific feature of the current class".

--


More information about the Digitalmars-d-bugs mailing list