Walter, here (http://doc.trolltech.com/3.1/signalsandslots.html) is a seed of
it. And now you cannot say what you are don't understand it at all. :)

Dr.Dizel wrote:

>Walter, here (http://doc.trolltech.com/3.1/signalsandslots.html) is a seed of
>it. And now you cannot say what you are don't understand it at all. :)
>  
>
I don't want to put words into Walters mouth but ... sometimes when smart people say they don't understand something they mean that they really do they understand it but they think there are better ways to do it.  I once had a very smart lecture who would always say "I know nothing",  of course the class knew he completely understood everything he was talking about.

-- 
-Anderson: http://badmama.com.au/~anderson/

In article <c8ciic$2vl0$1@digitaldaemon.com>, J Anderson says...

>... sometimes when smart people say they don't understand something they mean that they really do they understand it but they think there are better ways to do it.

Does he keep the silver bullet for this question in a black closed room? If do but why?

Dr.Dizel wrote:

> Walter, here (http://doc.trolltech.com/3.1/signalsandslots.html) is a seed
> of it. And now you cannot say what you are don't understand it at all. :)

Before rolling up that topic again: I have a pretty good feeling that mixins will give us everything we need for signals/slots. Actually trying to do it is left as a homework for those interested...

Norbert Nemec wrote:

> Dr.Dizel wrote:
> 
> 
>>Walter, here (http://doc.trolltech.com/3.1/signalsandslots.html) is a seed
>>of it. And now you cannot say what you are don't understand it at all. :)
> 
> 
> Before rolling up that topic again: I have a pretty good feeling that mixins
> will give us everything we need for signals/slots. Actually trying to do it
> is left as a homework for those interested...

Not really, but it does make implementing them a bit less copy/paste-y.

Unless there's some wrinkle to this that I'm not aware of (I think of signals and slots in a C#ish context), they've been easily possible within D for eons now.

http://andy.tadan.us/d/listener.d

 -- andy

"Dr.Dizel" <Dr.Dizel_member@pathlink.com> wrote in message news:c8ci8n$2v40$1@digitaldaemon.com...
> Walter, here (http://doc.trolltech.com/3.1/signalsandslots.html) is a seed
of
> it. And now you cannot say what you are don't understand it at all. :)
>
>

What you are all missing is that the signals and slots mechanism has a major difference than the observable/observer mechanism: in Trolltech's signals and slots, an object's slots are automatically destroyed when the object is destroyed.

This little detail makes it necessary for signals and slots to be implemented as part of the language, and not with templates. Slots must contain *weak* references to objects, and these references must not be checked by the garbage collector.

Achilleas Margaritis wrote:

> 
> "Dr.Dizel" <Dr.Dizel_member@pathlink.com> wrote in message news:c8ci8n$2v40$1@digitaldaemon.com...
>> Walter, here (http://doc.trolltech.com/3.1/signalsandslots.html) is a
>> seed
> of
>> it. And now you cannot say what you are don't understand it at all. :)
>>
>>
> 
> What you are all missing is that the signals and slots mechanism has a major difference than the observable/observer mechanism: in Trolltech's signals and slots, an object's slots are automatically destroyed when the object is destroyed.
> 
> This little detail makes it necessary for signals and slots to be implemented as part of the language, and not with templates. Slots must contain *weak* references to objects, and these references must not be checked by the garbage collector.

May it be, that this can be split up in two solvable cases:

* When you demand connections to be cut automatically when the receiver is deleted, you are obviously talking about objects that are not garbage collected but actively deleted. Therefore, the topic of weak references is not important.

* When, on the other hand, you do not actively delete the objects you are working with, then automatic cutting of connections is not an issue. Therefore, the receiver does not need to keep a reference to the sender. The reference from the sender to the receiver should not be a weak reference anyway (An object that can receive messages obviously is not garbage.)

In neither case you need weak references. Everything else should be possible in D as it is.

Looking at these two cases, you only need to consider for every class that implements slots whether it should be manually deleted or garbage collected. Depending on this, it would either get intelligent (i.e. auto-disconnecting) or dumb slots (i.e. plain member functions)

Norbert Nemec wrote:
> May it be, that this can be split up in two solvable cases:
> 
> * When you demand connections to be cut automatically when the receiver is
> deleted, you are obviously talking about objects that are not garbage
> collected but actively deleted. Therefore, the topic of weak references is
> not important.
> 
> * When, on the other hand, you do not actively delete the objects you are
> working with, then automatic cutting of connections is not an issue.
> Therefore, the receiver does not need to keep a reference to the sender.
> The reference from the sender to the receiver should not be a weak
> reference anyway (An object that can receive messages obviously is not
> garbage.)
> 
> In neither case you need weak references. Everything else should be possible
> in D as it is.
> 
> Looking at these two cases, you only need to consider for every class that
> implements slots whether it should be manually deleted or garbage
> collected. Depending on this, it would either get intelligent (i.e.
> auto-disconnecting) or dumb slots (i.e. plain member functions)

I, too, thought this, but especially in the case of GUIs, I no longer think that this is the case.  Consider the case of a GUI which is viewing a certain document.  Assume for the moment that there are two windows viewing the same document, perhaps a "normal" view and a "zoom" view.

In the signals & slots architecture, then, there is a signal associated with the document which is emitted when the data in the document changes.  There are slots in both window objects, which receive the signal.

Now, what happens when one of the windows is closed?  If each window is a simple object, then you can explicitly delete the object and explicitly disconnect the signals in the destructor.  But that becomes very inelegant when the window is a compound object.  The Zoom window, for instance, might actually look like this:

class ZoomWindow : FrameWindow {
  MenuBar menu;
  Graphics displayArea;
...
}

Let's assume for the moment that MenuBar and Graphics are both child classes of Window, because, at the low-level, they are windows in the GUI toolkit being used.

Presumably, the DocumentChanged signal is not actually connected to the ZoomWindow; it is connected to the Graphics object.  So, if we are to explicitly disconnect the signal, then we must explicitly delete the Graphics object as well as the ZoomWindow!  We've now introduced a rat's nest of recursive delete's, and have moved away from D's standard gc mechanism.

I used to be doubtful of the utility of weak references, but I'm starting to become convinced that they are very useful and should be implemented.

Setting the details of the example aside, it seems like there are going to be a lot of cases where an object in a GC system has multiple connections which should not necessarily preserve it.  Solving this will require a more direct approach.  You can create a widget management system that handles deletion by tracking all the connections and broadcasting messages as needed.


A sophisticated version would know all the parts that connect to X via a multimap of some kind.  The simple, but O(N), solution is to just send a message to everyone everywhere, of the form "Object with serial # 10133 is going away", and they can drop any pointers to it after finishing any ongoing transactions. After the message is delivered, the table-of-objects would remove its own reference.


A much more basic technique is a central hash table of objects - regular users only have a serial number, but have to handle non-existence cases.

If you can't handle the non-existence case in a particular object, then it needs a real reference.  This will actually be true a lot, usually when doing "real operations" on objects, so get a reference to each object at the beginning and handle the non-exist before committing to a transaction.  That way if the table entry is cleared you are covered.

This problem can be really thorny in distributed systems (particularly where performance is an issue - I've seen distributed systems written partly in assembler that used only refcounts... "dont get out of the boat").  It may be better to solve the problem explicitly in the design, rather than trying to create a cyclical reference graph with "automatic fall apart".

Kevin

This whole example still boils down to a design issue of the GUI library.

Widgets are resources, similar to open files, network connections etc. The concept of garbage collection does not really work well for this kind of object.

Plain objects only take up space on the heap. If a plain object is not referenced any more, all it does is to take up space on the heap. It does not really matter when that space is released, so we can forget about it and leave it to the GC to collect it whenever it needs space.

Resource objects on the other hand do not only take up space but, as the name sais, also hold a resource. You always should close a resource object manually after use. Maybe it is this act of "closing" that we should focus on, no matter whether closing and deleting of the object fall together or not. Automatic signal disconnection for widgets should happen at *closing* time.

GUI objects and Resource objects in general always have to "belong" so someone. Some object has to take care of closing them after use. This is unlike plain objects that are just referenced from many places and simply die when the last reference is cut. If a window containing several widgets is closed, of course, it has to recursively close all the children. A GUI library may do that automatically.

And for objects that own neither resources nor any resource objects? These do not need to be closed explicitely. They will just exist as long as they are referenced and drop dead once the last reference is cut. An incoming connection, of course, is just a plain reference in this respect. If there is the chance that the object might get signaled, it obviously still can react and therefore, it is not dead and should not be collected.

Weak references, therefore, are not linked to the question of signals and slots. They may be useful in many contexts, but they certainly are not *necessary* for signals/slots in any special way.


Russ Lewis wrote:

> Norbert Nemec wrote:
>> May it be, that this can be split up in two solvable cases:
>> 
>> * When you demand connections to be cut automatically when the receiver is deleted, you are obviously talking about objects that are not garbage collected but actively deleted. Therefore, the topic of weak references is not important.
>> 
>> * When, on the other hand, you do not actively delete the objects you are working with, then automatic cutting of connections is not an issue. Therefore, the receiver does not need to keep a reference to the sender. The reference from the sender to the receiver should not be a weak reference anyway (An object that can receive messages obviously is not garbage.)
>> 
>> In neither case you need weak references. Everything else should be possible in D as it is.
>> 
>> Looking at these two cases, you only need to consider for every class that implements slots whether it should be manually deleted or garbage collected. Depending on this, it would either get intelligent (i.e. auto-disconnecting) or dumb slots (i.e. plain member functions)
> 
> I, too, thought this, but especially in the case of GUIs, I no longer think that this is the case.  Consider the case of a GUI which is viewing a certain document.  Assume for the moment that there are two windows viewing the same document, perhaps a "normal" view and a "zoom" view.
> 
> In the signals & slots architecture, then, there is a signal associated with the document which is emitted when the data in the document changes.  There are slots in both window objects, which receive the signal.
> 
> Now, what happens when one of the windows is closed?  If each window is a simple object, then you can explicitly delete the object and explicitly disconnect the signals in the destructor.  But that becomes very inelegant when the window is a compound object.  The Zoom window, for instance, might actually look like this:
> 
> class ZoomWindow : FrameWindow {
>    MenuBar menu;
>    Graphics displayArea;
> ...
> }
> 
> Let's assume for the moment that MenuBar and Graphics are both child classes of Window, because, at the low-level, they are windows in the GUI toolkit being used.
> 
> Presumably, the DocumentChanged signal is not actually connected to the ZoomWindow; it is connected to the Graphics object.  So, if we are to explicitly disconnect the signal, then we must explicitly delete the Graphics object as well as the ZoomWindow!  We've now introduced a rat's nest of recursive delete's, and have moved away from D's standard gc mechanism.
> 
> I used to be doubtful of the utility of weak references, but I'm starting to become convinced that they are very useful and should be implemented.