Suggestion: signal/slot mechanism

[Agent Orange]

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)"


This is a great idea. Trolltech really has created a new style of event 
based programming. Its especially useful for IU systems. The signal slot 
pattern is a generalized observer pattern with late binding. The signals 
are fired at potential observers and resolved via string identifier at 
runtime; this allows a great deal of tool-code integration. signal slot 
libraries tend to be a hastle because the observers have to disconnect 
from their signals on destruction - you cant fire a signal at a dead 
object, but Qts moc makes takes care of all of that incredibly well. in 
qt signals and slots are like first class language constructs, and it 
becomes less of a hastle and more of an amazingly usefull tool. D would 
be just absolutely incredible if it supported signals and slots, or even 
just the observer pattern - perhaps something in phobos that hooks into 
object destruction.... another option is to create a tool such as 
trolltechs moc but even then you would have to require users to link a 
library or something; or would be nice to see this attached to something 
like ares. signals and slots give you anonymous typesafe callbacks that 
allow a whole new level of object oriented abstraction that most people 
unfortunately cant fully understand until they use them. walter has said 
before he doesnt quite know what signals and slots are. I recently used 
Qt on a project and I immediately fell in love with them similarly to 
the way I fell for D. A mariage of the two could possibly create an 
incredible new style of programming.