www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - signal slots library

reply Lutger <lutger.blijdestijn gmail.com> writes:
Finally I have an initial version of my signal slots library finished. 
You can get it at http://lutger.ifastnet.com/ or view the online 
documentation there. Hopefully all is in place, this is my first site 
and encounter with IE hacks...

Comments, critique etc. is most welcome.
Sep 24 2006
next sibling parent Kristian <kjkilpi gmail.com> writes:
On Sun, 24 Sep 2006 20:35:54 +0300, Lutger <lutger.blijdestijn gmail.com>  
wrote:

 Finally I have an initial version of my signal slots library finished.  
 You can get it at http://lutger.ifastnet.com/ or view the online  
 documentation there. Hopefully all is in place, this is my first site  
 and encounter with IE hacks...

 Comments, critique etc. is most welcome.
Thanks Lutger! I quickly glanced at the docs, and looks good. (Maybe this will find its way to Phobos some day, as I think there really should be a sslot lib in it...) :)
Sep 24 2006
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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.
Oct 12 2006
next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
Bastiaan Veelo wrote:
 http://svn.dsource.org/projects/dcouple/downloads/
Pardon for replying to my own message, but it appears that the latest version is still in the trunc, and has not been tarred into downloads yet. See the changelog at the bottom of the documentation. http://svn.dsource.org/projects/dcouple/trunk/managed/doc/index.html Bastiaan.
Oct 12 2006
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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.
Oct 13 2006
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
 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:
OK, that is enough for C++ (Qt) style programming where the programmer has to take care of deletion. However, in D it would be really nice to let the garbage collector do that.
 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.
 This avoids the problem 
 of objects / slots and signals needing to know about each other.
Is it a 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. Have fun! Bastiaan.
Oct 13 2006
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
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...
Oct 13 2006
prev sibling parent Josh Stern <josh_usenet phadd.net> writes:
On Fri, 13 Oct 2006 16:32:08 +0200, Bastiaan Veelo wrote:

 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:
OK, that is enough for C++ (Qt) style programming where the programmer has to take care of deletion. However, in D it would be really nice to let the garbage collector do that.
It seems like what is really needed is the ability to dynamically associate some type of callback list with finalization of objects. If there was a way to set a bit flag in the bookkeeping code for an object, then the overhead of this when it is not used would be just checking whether the flag is set. If it is, there would be an AA lookup on the object address to get the callback list. Disconnecting signal/slot bindings could be just one example of a callback. Another example where this would be really useful is for mixing GC and non GC'd code.
Oct 13 2006