Suggestion: signal/slot mechanism

[Bruno Medeiros]

Kristian 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 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 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.

> 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 

With a library, in D, S/S can be used as easy as calling functions.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D