"The last feature": overridable methods in interfaces
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Mon Feb 8 11:34:10 PST 2010
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
More information about the Digitalmars-d
mailing list