Max Samukha Wrote:
> >
> >I see. What you want is non-virtual MI.
> >I don't think that allowing the derived class to have two distinct
> >implementations for the same function prototype is a good idea.
> >Eiffel handles this by giving the programmer controls to select features and
> >rename them in the derived class which I think is better.
> >
> >// hypothetical syntax example
> >class FlippingBlipper : IBlipper, IFilpper {
> > mixin Flipper F;
> > mixin Blipper B;
> > // rename the inherited interface functions
> > alias IBlipper.nameCollision boo;
> > alias IFilpper.nameCollision foo;
> > // implement the now two distinct functions
> > void foo() { F.nameCollision(); }
> > void boo() { B.nameCollision(); }
> >}
> >
> >you can further subtype and the derived foo & boo will override the
> >respective interfaces.
>
> Yes, but what if nameCollision is a virtual function called somewhere
> in the template mixin? Your example has effectively removed the
> virtuality.
>
it doesn't remove virtuality. Virtual functions are stored as pointers in the
vtable. with my suggested solution the idea is that the same pointer in the
vtable gets a new name in the derived class.
when you mixin the template into the derived class the compiler would resolve
nameCollision to the new name "foo" because of the renaming rule in the derived
class.
> If your mixin template contains unimplemented or partially implemented
> virtual functions (for example, in case of an abstract base type), you
> have to derive another class to (re)implement them.
>
> Ok, I'm not arguing that mixins+interfaces cannot be used to emulate
> multiple subtyping. I'm arguing it has problems that may force one to
> resort to horrible hacks.
>
> How is it better than the solution provided by 'alias this' and nested
> classes? 'alias this' doesn't require mixin templates, handles name
> conflicts nicely, allows subtyping of value types, allows
> (re)implementing base functions directly in the subtype (using nested
> classes).
>
I don't think I want non virtual MI in D since it is more trouble than it's
worth. but *if* we discuss this, I think my suggested semantics are simpler.
The syntax probably can be much better but that's a secondary issue IMO.
> BTW, your example rewriten with 'alias this' looks cleaner, IMHO:
>
> class Flipper { ... }
> class Blipper { ... }
>
> class FlippingBlipper {
> Flipper flipper;
> Blipper blipper;
>
> this { blipper = new Blipper; flipper = new Flipper; }
>
> alias this flipper;
> alias this blipper;
>
> void foo() { blipper.nameCollision; }
> void bar() { flipper.nameCollision; }
> }
>
> No interfaces, no templates, no renaming. Problem solved. Almost. We
> have to be able to instantiate classes in-place to avoid unnecessary
> allocations.
with my design:
class Foo : FlippingBlipper {
override foo ...
override bar ...
}
IFlipper obj = new Foo;
obj.nameCollision; // will call Foo.bar
I don't think that's possible with your design.
besides, alias this is a hack. a better mechanism would be to have compile-time
inheritance, IMO.
