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