"The last feature": overridable methods in interfaces

[Jacob Carlborg]

On 2/8/10 06:37, Andrei Alexandrescu wrote:
> Walter has now implemented final methods in interfaces and also
> contracts in interfaces, both of which I think are just awesome.
>
> We figured that essentially he artificially disallows interfaces from
> providing bodies for methods. I think that's a gratuitous limitation;
> the only distinguishing quality of an interface is that it has no state.
> Other than that, interfaces can always offer overridable functions that
> by default offer functionality in terms of existing interface functions.
> For example:
>
> interface Stack(T)
> {
> void push(T);
> void pop();
> @property ref T top();
> @property bool empty();
> T belowTop()
> {
> auto t = top;
> pop();
> auto result = top;
> push(t);
> }
> }
>
> The default implementation of belowTop does a fair amount of work. A
> particular implementation might just use that or override it with a more
> efficient implementation.
>
> Many more examples can be imagined, but I'm looking for a killer one, or
> perhaps a killer counterexample (e.g. when would an interface-defined
> method be really bad?)
>
> Your thoughts welcome.
>
>
> Andrei

I only see two differences with abstract classes: interfaces can't have 
instance (and class?) variables and you can inherit from multiple 
interfaces. Am I missing something? Is this really necessary? Isn't 
abstract classes enough? Does this have similar problems (or the same) 
as multiple inheritance?


/Jacob Carlborg