View mode: basic / threaded / horizontal-split · Log in · Help
December 02, 2004
Signals and slots?
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
Re: Signals and slots?
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
Re: Signals and slots?
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
Re: Signals and slots?
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
Re: Signals and slots?
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
Re: Signals and slots?
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
Re: Signals and slots?
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
Re: Signals and slots?
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
Re: Signals and slots?
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
Re: Signals and slots?
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
Top | Discussion index | About this forum | D home