• Lutger <lutger.blijdestijn gmail.com> Sep 24 2006
• Kristian <kjkilpi gmail.com> Sep 24 2006
• Bastiaan Veelo <Bastiaan Veelo.net> Oct 12 2006
• Bastiaan Veelo <Bastiaan Veelo.net> Oct 12 2006
• Lutger <lutger.blijdestijn gmail.com> Oct 13 2006
• Bastiaan Veelo <Bastiaan Veelo.net> Oct 13 2006
• Lutger <lutger.blijdestijn gmail.com> Oct 13 2006
• Josh Stern <josh_usenet phadd.net> Oct 13 2006

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.

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...) :)

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.

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.

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.

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.

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...

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.