"The last feature": overridable methods in interfaces

[Jacob Carlborg]

On 2/8/10 14:03, Andrei Alexandrescu wrote:
> 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

The obvious solution as I see it would have been using "regular" 
interfaces and template mixins. But that fails since the mixed in 
methods can't overload on the already present methods.

Have traits (http://en.wikipedia.org/wiki/Trait_%28computer_science%29) 
ever been considered?