Suggestion: signal/slot mechanism

[Bruno Medeiros]

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.

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