Suggestion: signal/slot mechanism

Kristian kjkilpi at gmail.com
Mon Sep 4 07:28:18 PDT 2006


On Sun, 03 Sep 2006 20:08:36 +0300, Kristian <kjkilpi at gmail.com> wrote:

> On Sun, 03 Sep 2006 13:01:28 +0300, Bruno Medeiros  
> <brunodomedeiros+spam at com.gmail> wrote:
>> Kristian wrote:
>>> It would be nice if D had a signal/slot mechanism similiar to Qt:
>>> http://doc.trolltech.com/4.1/signalsandslots.html
>>>  It's an elegant way to handle messages sent between objects. It beats
[snip]


Ludger wrote:

> I think there are benefits / downsides to both options of language and  
> library implementation. Personally I favor a library option, and if it  
> would be included in some (de facto or official) standard library that  
> would be good indeed.
>
>  In C++ the existing library solutions are very nice and prove that a  
> preprocessor like QT uses is not needed at all. I think it can be done  
> in D even better, because of delegate support and template features.
>
>  The benefit of a library solution is less language bloat, more  
> flexible   and possible competition. Some libraries also perhaps don't  
> want to use the signal-slot mechanism, like harmonia which prefers to  
> use sinking-bubbling.


Bruno Medeiros wrote:

> I see, so a S/S object also knows which signals point to his slots.  
> Still, a base class is not required, a mixin can do the job nearly as  
> well.
>
>> I think everybody will agree if I say that the optimal solution would  
>> be D supporting S/S mechanism directly.
>>
>
> I disagree. If D can support S/S without additional languages  
> constructs, and with nearly the same easy of use as Qt's, then that's  
> enough.


Well, I think the key sentence here is "almost as easy as". Will it be  
easy enough for the majority?

The S/S mechanism is a very simple structure. If you build it 'right',  
then there is no room for competition (because you cannot make it  
simplier). And being simple, it won't bloat the language. Instead it'll  
extend the language 'naturally'.

Mixins and templates would make the mechanism quite complex. That would  
bloat the *code*.

For example:

/* ----- Qt-styled way with some modifications */

class Foo {
     void setValue(int value) {
         ...
         emit valueChanged();
         emit valueChanged(oldVal, value);
     }

     signal valueChanged();
     signal valueChanged(int oldValue, int newValue);
}

class Bar {
     this() {
         foo = new Foo;
         connect foo.ValueChanged() to handleFoo();

         foo2 = new Foo;
         connect foo2.valueChanged(int, int) to handleFoo(int, int);
     }

     void handleFoo() {...}
     void handleFoo(int oldValue, int newValue) {...}

     Foo foo, foo2;
}


/* ----- dcouple-styled way */

// The Widget class implements the S/S handling.
// It's derived from dcouple's SignalSlotManager.
// Its implementation is omited here.

class Foo : Widget {
     this() {
         sigValueChanged1 = new Signal!()(this);
         sigValueChanged2 = new Signal!(int, int)(this);
     }

     void setValue(int value) {
         ...
         sigValueChanged1.emit();
         sigValueChanged2.emit(oldVal, value);
     }

     Signal!() sigValueChanged1;
     Signal!(int, int) sigValueChanged2;
}

class Bar : Widget {
     this() {
         foo = new Foo;
         slotHandleFoo1 = new Slot!()(this, &handleFoo1);
         connect(foo.sigValueChanged1, slotHandleFoo1);

         foo2 = new Foo;
         slotHandleFoo2 = new Slot!(int, int)(this, &handleFoo2);
         connect(foo2.sigValueChanged2, slotHandleFoo2);
     }

     void handleFoo1() {...}
     void handleFoo2(int oldValue, int newValue) {...}

     Slot!() slotHandleFoo1;
     Slot!(int, int) slotHandleFoo2;

     Foo foo, foo2;
}

I am not saying that dcouple is poorly written or anything (far from it!),  
but the benefits of the direct support is obvious IMHO:

- Less code (and less potential bugs).
- Clearer syntax which is easier to read/write.
- Signals can be connected to any object and function.
- No need to use a base class (or mixins).
- Function overloads can be used.
- Guaranteed to be bug free.



More information about the Digitalmars-d mailing list