Suggestion: signal/slot mechanism

[Kristian]

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  
>> event table declarations used by other GUI libraries IMHO.
>>  It would make D a lot more appealing language to write GUI  
>> applications. Think of wxWidgets written in D... ;)
>>   I think it would be quite simple to build a S/S support for a  
>> compiler (at first glance, at least). For example:
>>  The 'Object' class has a pointer to S/S data (it's null if the object  
>> don't currently use signals/slots). S/S data holds a slot list for each  
>> signal. It also holds a list of objects that have slot(s) connected to  
>> this object's signal(s). This list is used to disconnect necessary  
>> slots at a destruction of the object.
>>  When the compiler reads a 'emit X' statement, it will do two things.  
>> First, it generates an id for the signal which is used to retrieve a  
>> correct slot list.
>>  Second, the compiler puts the signal's parameters to the stack as it  
>> would call a corresponding function. Instead, the  
>> 'Object._emit_signal(id)' function (or something) is called, where 'id'  
>> is the generated id. (Note that there are no function bodies for  
>> signals.) '_emit_signal()' retrieves the correct slot list, and calls  
>> all the slots (delegates) in it. Finally the parameters are removed  
>> from the stack.
>>  Of course, slots should not modify their parameters so that all the  
>> slots will receive the same parameter values. Hence slots should not  
>> use the 'out type'. There is a market for a 'const type' here... *wink*
>>   Maybe there should be no slot keyword at all as there is in Qt. You  
>> don't need to declare a function to be a slot; all the (virtual)  
>> functions can be used with signals.
>>  Because the return values of all the signals are void, the void  
>> typeword could be removed from signal declarations.
>>  signal clicked();
>>  signals:
>> clicked();
>> clicked(int button);
>>   BTW, Qt generates ids for signals as follows:
>>  signals:
>> void clicked(int button, bool isMoved);
>> -> the id is a string "clicked(int,bool)"
>
> The Signal and slots pattern is little more than an abstraction for  
> languages that do not support delegates (and dynamic arrays). Which is  
> not the case for D:
>
>    // Declare a signal:
>    void delegate(Button, int)[] someSignal;
>
>    // Connect a slot to a signal:
>    someSignal ~= foo.someSlot;
>
>    // emit the signal
>    foreach(dg; someSignal)
>      dg(myButton, myInt);
>
> The only limitation I see with D so far, is on the emit part. You can't  
> create an emit function that works like this:
>    emit(someSignal, myButton, myInt);
> and that would do the same as that foreach. Because you cannot do  
> "parameterized"(whether compile time or runtime) function calls.
>

Automatic S/S disconnection at object destructions should also be  
implemented, usually, which requires the use of a base class.

I think everybody will agree if I say that the optimal solution would be D  
supporting S/S mechanism directly.

It would make using of signals/slots as easy as calling of functions, for  
instance. But if Walter (and D community) thinks that the S/S mechanism is  
not important enough to be added to D specs (ever), then Phobos should  
have a S/S library (in the future). It would make implementation of  
classes having signals/slots more tedious though. Fortunately using of  
such classes would be as easy (I looked at some examples of dcouple).