Jump to page: 1 2
Thread overview
Signals and slots?
Dec 02, 2004
Georg Wrede
Dec 02, 2004
Zz
Dec 02, 2004
Russ Lewis
Dec 03, 2004
Georg Wrede
Dec 03, 2004
Georg Wrede
Dec 03, 2004
Russ Lewis
Dec 03, 2004
Russ Lewis
Dec 03, 2004
Georg Wrede
Dec 04, 2004
Russ Lewis
Dec 04, 2004
Georg Wrede
Dec 04, 2004
Ben Hinkle
Dec 04, 2004
Russ Lewis
Dec 07, 2004
Georg Wrede
Dec 02, 2004
pragma
Dec 04, 2004
Bastiaan Veelo
Dec 04, 2004
Ben Hinkle
Dec 07, 2004
Georg Wrede
Dec 05, 2004
Dr.Dizel
Dec 09, 2004
Bastiaan Veelo
Dec 10, 2004
John Reimer
December 02, 2004
Hi!

How hard would it be to have signals&slots included in the D spec?

An intro at http://doc.trolltech.com/3.3/signalsandslots.html describes the idea as far as Qt is concerned, but this might be a generally useful thing in any OO language?

Since they have implemented this with a couple of preprocessor definitions, it probably wouldn't be too hard to incorporate in the D language core?

Code shops usually have their staff writing stock classes between assignments, and having signals&slots would make these classes handier to use. And large programming projects would benefit from looser coupling between objects.

I'm not saying SS should be used _instead_ of regular object methods, just that they add value and versatility to a class. And adding some SS to already existing classes could make them usable in new contexts.

(I know, I know) this might be a little too late for D 1.0. :-(

Then again, having SS in D 1.0 could make writing usable libraries easier. By D 2.0 we'd have a real mean package!

Writing games, UI, multithreaded, real-time, control, OS, ... you name it, SS would be of help.



December 02, 2004
Look at http://libsigc.sourceforge.net/ which implements it in c++ without
all that pre-processor stuff.
There is also one in Boost.

Zz



"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:conii3$tkv$1@digitaldaemon.com...
> Hi!
>
> How hard would it be to have signals&slots included in the D spec?
>
> An intro at http://doc.trolltech.com/3.3/signalsandslots.html describes the idea as far as Qt is concerned, but this might be a generally useful thing in any OO language?
>
> Since they have implemented this with a couple of preprocessor
definitions,
> it probably wouldn't be too hard to incorporate in the D language core?
>
> Code shops usually have their staff writing stock classes between
assignments,
> and having signals&slots would make these classes handier to use. And
large
> programming projects would benefit from looser coupling between objects.
>
> I'm not saying SS should be used _instead_ of regular object methods, just that they add value and versatility to a class. And adding some SS to already existing classes could make them usable in new contexts.
>
> (I know, I know) this might be a little too late for D 1.0. :-(
>
> Then again, having SS in D 1.0 could make writing usable libraries easier. By D 2.0 we'd have a real mean package!
>
> Writing games, UI, multithreaded, real-time, control, OS, ... you name it, SS would be of help.
>
>
>


December 02, 2004
People have suggested exactly this before.  I am going to re-read that page on Qt Signals (partly just because they sound interesting), but I think the general conclusion was that signals could be pretty well handled with delegates.

The one big problem (as I remember it) is garbage collection of objects which are the target of signals.  You can't gc an object until all references to it (including references which are part of delegates) are gone.  Likewise, if you manually delete something, you need a way to inform whoever holds the delegate to not call it (since the object is no longer valid).

People have argued that this is a place where weak references would be very useful.

I (may) post more comments later after I've reread the article in detail.

December 02, 2004
I thought this sounded familiar, so I went looking.  Apparently, it's already out there.

http://www.dsource.org/projects/dcouple/

From the Readme.txt in the svn/trunk:

The dcouple project is a place for experimenting towards an effective implementation of the "signal and slot" call-back concept in D. As the basics have already been illustrated by others, the main contribution of this project will be usage issues (syntax) and performance in a garbage collected system. The ability to break all connections to a particular slot or from a particular signal is essential in this respect, and is reflected in the name of this project. Hopefully, a library will result that can be included into some "standard" library (phobos, deimos, phoenix, whatever) and form the basis of a Qt-like GUI library.

In article <conii3$tkv$1@digitaldaemon.com>, Georg Wrede says...
>
>Hi!
>
>How hard would it be to have signals&slots included in the D spec?
>
>An intro at http://doc.trolltech.com/3.3/signalsandslots.html describes the idea as far as Qt is concerned, but this might be a generally useful thing in any OO language?
>
>Since they have implemented this with a couple of preprocessor definitions, it probably wouldn't be too hard to incorporate in the D language core?
>
>Code shops usually have their staff writing stock classes between assignments, and having signals&slots would make these classes handier to use. And large programming projects would benefit from looser coupling between objects.
>
>I'm not saying SS should be used _instead_ of regular object methods, just that they add value and versatility to a class. And adding some SS to already existing classes could make them usable in new contexts.
>
>(I know, I know) this might be a little too late for D 1.0. :-(
>
>Then again, having SS in D 1.0 could make writing usable libraries easier. By D 2.0 we'd have a real mean package!
>
>Writing games, UI, multithreaded, real-time, control, OS, ... you name it, SS would be of help.
>
>
>

- Pragma
December 03, 2004
In article <connr8$172e$1@digitaldaemon.com>, Russ Lewis says...
>
>People have suggested exactly this before.  I am going to re-read that page on Qt Signals (partly just because they sound interesting), but I think the general conclusion was that signals could be pretty well handled with delegates.

I can't imagine teaching delegates in the first semester. But SS I could!
>The one big problem (as I remember it) is garbage collection of objects which are the target of signals.

Heh, I just saw the light. What if the target object _sends a signal_ at its demise?

The compiler could implicitly insert this in the destructor of SS-aware objects.

From an object's point of view, all SS is about is throwing signals up in the air. If someone is interested, then fine. You neither care or even know. So yelling "I die" can be heard by the SS system itself (and whoever else might be interested).



December 03, 2004
In article <copc32$h4q$1@digitaldaemon.com>, Georg Wrede says...
>
>In article <connr8$172e$1@digitaldaemon.com>, Russ Lewis says...
>>
>>People have suggested exactly this before.  I am going to re-read that page on Qt Signals (partly just because they sound interesting), but I think the general conclusion was that signals could be pretty well handled with delegates.
>
>I can't imagine teaching delegates in the first semester. But SS I could!
>>The one big problem (as I remember it) is garbage collection of objects which are the target of signals.
>
>Heh, I just saw the light. What if the target object _sends a signal_ at its demise?
>
>The compiler could implicitly insert this in the destructor of SS-aware objects.
>
>From an object's point of view, all SS is about is throwing signals up in the air. If someone is interested, then fine. You neither care or even know. So yelling "I die" can be heard by the SS system itself (and whoever else might be interested).

Oh, and to top this off: have the SS target references not counted by the GC. This way, when an object becomes otherwise unreferenced, the GC collects the object, and its destructor informs the SS.




December 03, 2004
Georg Wrede wrote:
> In article <connr8$172e$1@digitaldaemon.com>, Russ Lewis says...
> 
>>People have suggested exactly this before.  I am going to re-read that page on Qt Signals (partly just because they sound interesting), but I think the general conclusion was that signals could be pretty well handled with delegates.
> 
> I can't imagine teaching delegates in the first semester. But SS
> I could!

Different perspectives, I guess.  To me, delegates seem very straightfoward (a simple step forward from function pointers) while SS seem very advanced.

>>The one big problem (as I remember it) is garbage collection of objects which are the target of signals.
> 
> Heh, I just saw the light. What if the target object _sends a signal_
> at its demise?
> 
> The compiler could implicitly insert this in the destructor of SS-aware objects.
> 
> From an object's point of view, all SS is about is throwing signals
> up in the air. If someone is interested, then fine. You neither care
> or even know. So yelling "I die" can be heard by the SS system itself (and whoever else might be interested).

The problem is race conditions.  You have to make sure that everybody receives the "I die" signal before any more signals are dispatched, since those signals might be tied to a slot in the dying object.  If you're multithreaded, it gets even worse, since this probably means that you have have to block all other signal dispatch threads (i.e. go single-threaded for a while), which becomes even harder if you have two objects dying at the same time (deadlock possibilities).

Certainly, you can solve these problems.  But it's a non-trivial thing, and I really don't think that non-trivial things should be done by the compiler.  Do it in a library, first.

Later, in 10 years or so, if we are all using signals & slots, and we all have come to a consensus about the "right" way to do them, then the next language can implement them for us more automatically.  But (IMHO) we don't want to put functionality into the compiler until the programming community has come to that sort of consensus.

December 03, 2004
Georg Wrede wrote:
> In article <copc32$h4q$1@digitaldaemon.com>, Georg Wrede says...
> Oh, and to top this off: have the SS target references not counted
> by the GC. This way, when an object becomes otherwise unreferenced,
> the GC collects the object, and its destructor informs the SS.

Right, that's exactly what weak references are.

December 03, 2004
In article <coq7e3$1pcb$1@digitaldaemon.com>, Russ Lewis says...
>
>Georg Wrede wrote:
..
>> From an object's point of view, all SS is about is throwing signals up in the air. If someone is interested, then fine. You neither care or even know. So yelling "I die" can be heard by the SS system itself (and whoever else might be interested).
>
>The problem is race conditions.  You have to make sure that everybody receives the "I die" signal before any more signals are dispatched, since those signals might be tied to a slot in the dying object.  If you're multithreaded, it gets even worse, since this probably means that you have have to block all other signal dispatch threads (i.e. go single-threaded for a while), which becomes even harder if you have two objects dying at the same time (deadlock possibilities).

I did some rethinking.

If someone dies, it actually is nobody's business. So we should skip the "I die" message entirely. Have SS just check for obj != null before dispatching the signal.

Nobody should be interested in whether there is anybody listening, so who cares if someone dies.

Race Conditions -- how does D currently handle simultaneous calling of a method in a dying object? How, or whether, it is currently taken care of, is good enough for SS. Nothing more is needed.


December 04, 2004
Georg Wrede wrote:
> In article <coq7e3$1pcb$1@digitaldaemon.com>, Russ Lewis says...
> 
>>Georg Wrede wrote:
> 
> ..
> 
>>>From an object's point of view, all SS is about is throwing signals
>>>up in the air. If someone is interested, then fine. You neither care
>>>or even know. So yelling "I die" can be heard by the SS system itself (and whoever else might be interested).
>>
>>The problem is race conditions.  You have to make sure that everybody receives the "I die" signal before any more signals are dispatched, since those signals might be tied to a slot in the dying object.  If you're multithreaded, it gets even worse, since this probably means that you have have to block all other signal dispatch threads (i.e. go single-threaded for a while), which becomes even harder if you have two objects dying at the same time (deadlock possibilities).
> 
> 
> I did some rethinking.
> 
> If someone dies, it actually is nobody's business. So we should skip
> the "I die" message entirely. Have SS just check for obj != null
> before dispatching the signal.

That would require that the dying object know about all delegates which point to it, and have the ability to zero out their pointers.  That's doable, but again, it's complexity better left to an (optional) library.

> Nobody should be interested in whether there is anybody listening,
> so who cares if someone dies.
> 
> Race Conditions -- how does D currently handle simultaneous calling
> of a method in a dying object? How, or whether, it is currently taken care of, is good enough for SS. Nothing more is needed.

Simple.  We don't GC an object until all references are gone, so that never becomes an issue.

If you manually delete an object, then you are responsible to have already cleaned up all of the lingering references...which is exactly like the old C/C++ way of doing things.

« First   ‹ Prev
1 2