"The last feature": overridable methods in interfaces

retard re at tard.com.invalid
Mon Feb 8 08:58:53 PST 2010


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.



More information about the Digitalmars-d mailing list