signal slots library

[Lutger]

Bastiaan Veelo wrote:
> Hi Lutger,
> 
> I once had a project like that, it was a fun exercise.
> http://svn.dsource.org/projects/dcouple/trunk/managed/doc/index.html
> http://www.dsource.org/forums/viewforum.php?f=32
> http://svn.dsource.org/projects/dcouple/downloads/
> I wish that some of the new language features were available back then. 
> My aim was mainly to arrive at an easy and readable API or syntax, 
> because that was a concern in some of the threads in the newsgroup back 
> then. Another objective was the management of connections, so they are 
> cleaned up when senders or receivers are deleted.
> 
> I quickly browsed your documentation, but could not find the answer to 
> an important question:
> 
> What happens to an object when only connections exist and it is not 
> otherwise referenced anymore? Does it get collected by the garbage 
> collector, and does it disconnect cleanly when it does?
> 
> The answer for my implementation is no, unfortunately, but Uwe Salomon 
> got it right. 
> http://www.uwesalomon.de/code/indigo/files/core/cmdtarget-d.html
> 
> I also think that there should be a Signals and Slots implementation in 
> the "standard" library, but it should be one that is invisible to the 
> garbage collector, and works well with it!
> 
> 
> Best regards,
> Bastiaan Veelo.

Hi, I know about dcouple, I studied it a bit for my first 
implementation. Nice job there, also on the documentation.

To answer your question honestly I'm not exactly sure if unreferenced 
objects get garbage collected, but if they get deleted they are safely 
disconnected:
Instead of storing references to an object in the signal, I took the 
approach of giving each object which has slots an unique identifier 
(mixin, no base class needed). This identifier is stored in a AA and 
reference counted, each managed slot in the signal also know's it's ID, 
so the signal can check the validity of a slot. This avoids the problem 
of objects / slots and signals needing to know about each other.
As for garbage collection, I don't know (or forgot) if taking a delegate 
from an object counts as a reference that keeps the object alive. I 
would assume so, as it has a pointer to the object. I'll check Uwe 
Salomon's code for this issue.

Regarding language features, I was very happy with all the improved 
template support (IFTI!), this made it very easy to support different 
callable types.

If I find some time and motivation I will update the thing, I'd like to 
do blocking and grouping slots.