signal slots library

[Lutger]

Bastiaan Veelo wrote:
<snip>
>> 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.
> 
> So each time a signal is sent to a slot, it searches the AA to check 
> whether the object is still alive? That seems a bit of an unnecessary 
> overhead.

Indeed it is, but only for managed delegates. AA lookup is reasonably 
fast though. This also makes it safe to delete a slot while emitting a 
signal.

>> This avoids the problem of objects / slots and signals needing to know 
>> about each other.
> 
> Is it a problem?

Well not really but you have to make the object also be aware of the 
signal to let it 'unregister' itself, so there will be a cyclic 
reference and I found it gets a little messy this way. But yes, my 
implementation didn't really solve that problem:

>> 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.
> 
> Correct. The concept of weak pointers has been proposed to the newsgroup 
> a long time ago, which would do as you hoped they did.
> 
>> I'll check Uwe Salomon's code for this issue.
> 
> He uses malloc and free, if I remember well.

I remember that now, a weak reference is what you need, this also came 
up in the recent signal-slots thread. Didn't think of malloc when I 
implemented it. I should change my implementation to make use of that.

 > Have fun!
 >
 > Bastiaan.

Thanks, I've never done much low level stuff like casting malloc'ed 
voids* even in C++, sounds like good fun...