interface + mixin combination

Bill Baxter wbaxter at gmail.com
Sat Oct 28 01:03:23 PDT 2006


Chris Nicholson-Sauls wrote:
> 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


Yeh, I was thinking that too.  Having both a with mixin and without 
mixin version seems frequently necessary.

Maybe just use a superinterface?

interface ISlotTracking
{
     // just the interface part
     void _registerCallback(void delegate(Object));
     void _removeCallbacksFrom(Object object);
}

interface MSlotTracking : ISlotTracking
{
     // ISlotTracking interface + implementation mixin
     mixin SlotTracking;
}

This is a pretty minor thing in the grand scheme of things, though. 
Definitely post 1.0.  C++ has limped along fine with the inherit class + 
macro implementation trick.

--bb



More information about the Digitalmars-d mailing list