"The last feature": overridable methods in interfaces

[Andrei Alexandrescu]

retard wrote:
> Mon, 08 Feb 2010 07:03:43 -0600, 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.
> 
> I really wonder why you're doing this. NIH. Ever heard or Scala and 
> traits? I'm sorry, but you didn't invent this feature - giving some kind 
> of attribution would be honest. I can imagine how this proposal goes 
> forward. Suddenly D 2 gets almost exactly the same feature (+ contracts) 
> as Scala has had for a long time and somehow you get all the credit in 
> the practical (C++/D) PL community.

This one really takes the cake. Do you really believe I'm in this for 
snatching credit? Sheesh.

I know of Scala's traits. They are different from overridable methods in 
interfaces, which are not nearly interesting enough to bring fame and 
fortune to anyone.


Andrei