"The last feature": overridable methods in interfaces

[Andrei Alexandrescu]

Jacob Carlborg wrote:
> 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?

I think lack of state is indeed the only difference. The multiple
inheritance bit makes all the difference, so I think abstract classes
are not enough. A designer who wants to define some methods in an
interface is forced at design time to choose an abstract class over an
interface, thus severely limiting clients.

Andrei