interface + mixin combination

[Chris Nicholson-Sauls]

Bill Baxter wrote:
> Looking at Lutger's new sigslot code, it occurred to me that this is 
> probably a pretty common (and useful) combination:
> 
>> class Receiver : ISlotTracking
>> {
>>     void handleClick() { writefln("button clicked"); }
>>     mixin SlotTracking;
>> }
> 
> 
> I.e. using both a) derivation from an interface and b) a mixin.
> 
> I've seen similar C++ GUI libraries, where a macro takes the place of 
> the mixin.   Examples I know of include
> 
> Qt - derive from QObject and use the QOBJECT macro
> wx - derive from wxObject and use the DECLARE_CLASS macro
> FOX - derive from FXObject and use FXDECLARE macro
> 
> It's a useful combo which is similar to regular class inheritance, but 
> different in that the implementation/behavior is defined locally and 
> non-virtually rather than being inherited from the base class.
> 
> The obvious syntax for it would be to just allow 'mixin' to appear in an 
> interface.
> 
> I.e. for Lutger's code:
> interface ISlotTracking
> {
>     void _registerCallback(void delegate(Object));
>     void _removeCallbacksFrom(Object object);
>     mixin SlotTracking;
> }
> 
> It's basically a replacement for multiple inheritance.
> 
> Would it be useful?  Any issues I've overlooked?
> 
> --bb

It is a very common idiom, and your proposal might have merit.  Except that -- at least in 
my personal practice, mind you -- the idea is to provide via the mixin only a "standard" 
or "minimal" implementation.  The path needs to stay open for class designers to do 
something unusual if the case warrants it.

That said, I do still like the spirit of the proposal: maybe if there were a way for the 
class designer to specify this behavior in the inheritance syntax, instead?  Alas, I can't 
immediately think of anything clean and concise.

-- Chris Nicholson-Sauls