Digital Mars - digitalmars.D - Signals and slots?

↑ ↓ ← → Georg Wrede <Georg_member pathlink.com> writes:

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.

Dec 02 2004

↑ ↓ ← → "Zz" <Zz Zz.com> writes:

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


 it probably wouldn't be too hard to incorporate in the D language core?

 Code shops usually have their staff writing stock classes between


 and having signals&slots would make these classes handier to use. And


 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.

Dec 02 2004

↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

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.

Dec 02 2004

↑ ↓ ← → Georg Wrede <Georg_member pathlink.com> writes:

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

Dec 03 2004

↑ ↓ ← → Georg Wrede <Georg_member pathlink.com> writes:

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.

Dec 03 2004

↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

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.

Dec 03 2004

↑ ↓ ← → Georg Wrede <Georg_member pathlink.com> writes:

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.

Dec 03 2004

↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

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.

Dec 03 2004

↑ ↓ ← → Georg Wrede <Georg_member pathlink.com> writes:

In article <cor3q6$1ls$1 digitaldaemon.com>, Russ Lewis says...
Georg Wrede wrote:


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 


I take it that you have connected all sending objects with delegates
to all those interested in their signals? Thus, 100 sending objects
emitting 10 different signals, and 100 receiving objects, each 
interested in all of them, gives 100*100*10 = 100_000 connections.
Additionally, using delegates, every sending object would "know" 
the recipient?

If all signals are sent via SS Dispatch, then we'd have
100*10 + 10*100 = 2000 connections, only 2% of the former.

If the pointers in SS Dispatch are not reference counted, then
SS objects should signal it from their destructor. A semaphore
in the Dispatch table could guarantee that the destructor does
not return before same-time signals have returned.

BTW, the Dispatch is only interested in signal receiving objects.

doable, but again, it's complexity better left to an (optional) library.


I agree that new things should be made library, and only later
considered for inclusion into the language. But I can't figure out
how you could end up with a convenient syntax for SS then. Example:

#   // (C++ from QT)
#   class Foo : public QObject
#   {
#       Q_OBJECT
#   public:
#       Foo();
#       int value() const { return val; }
#   public slots:
#       void setValue( int );
#   signals:
#       void valueChanged( int );
#   private:
#       int val;
#   };
#

Of course, one could always run the code through a preprocessor,
but that would be against the spirit of D, right?

 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.


Hmm. This suggests that (if not else, then for Asserts to be possible)
you can ask the GC how many references currently point to an object.
Like when you think there's only one reference to an object and it
turns out there are 5.

Dec 04 2004

↑ ↓ ← → "Ben Hinkle" <ben.hinkle gmail.com> writes:

"Georg Wrede" <Georg_member pathlink.com> wrote in message 
news:cosgvu$23g0$1 digitaldaemon.com...
 In article <cor3q6$1ls$1 digitaldaemon.com>, Russ Lewis says...
Georg Wrede wrote:


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


 I take it that you have connected all sending objects with delegates
 to all those interested in their signals? Thus, 100 sending objects
 emitting 10 different signals, and 100 receiving objects, each
 interested in all of them, gives 100*100*10 = 100_000 connections.
 Additionally, using delegates, every sending object would "know"
 the recipient?

 If all signals are sent via SS Dispatch, then we'd have
 100*10 + 10*100 = 2000 connections, only 2% of the former.


I don't know how SS stores the connection information so it is possible it 
compresses it for special cases but I would guess in reality the set of 
connections is not very compressable. In my experience you typically only 
have 0, 1 or 2 objects listening for a given signal from a given object so 
who cares how it compresses?

 If the pointers in SS Dispatch are not reference counted, then
 SS objects should signal it from their destructor. A semaphore
 in the Dispatch table could guarantee that the destructor does
 not return before same-time signals have returned.

 BTW, the Dispatch is only interested in signal receiving objects.

doable, but again, it's complexity better left to an (optional) library.


 I agree that new things should be made library, and only later
 considered for inclusion into the language. But I can't figure out
 how you could end up with a convenient syntax for SS then. Example:

 #   // (C++ from QT)
 #   class Foo : public QObject
 #   {
 #       Q_OBJECT
 #   public:
 #       Foo();
 #       int value() const { return val; }
 #   public slots:
 #       void setValue( int );
 #   signals:
 #       void valueChanged( int );
 #   private:
 #       int val;
 #   };
 #

 Of course, one could always run the code through a preprocessor,
 but that would be against the spirit of D, right?


see my post using multicast delegates. I think the user code is cleaner than 
the SS example.

 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.


 Hmm. This suggests that (if not else, then for Asserts to be possible)
 you can ask the GC how many references currently point to an object.
 Like when you think there's only one reference to an object and it
 turns out there are 5.


There isn't an API to ask the GC how many references point to an object. The 
current implementation of the GC uses a mark-sweep algorithm so it only 
figures out if an object has live references during the GC run and otherwise 
an object has no idea if it is live or not - kindof a bummer to not know if 
you are alive but so it goes :-)

-Ben

Dec 04 2004

↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

So you create an intermediate object between the various senders and the 
various receievers.  My argument still holds: whoever calls the 
receivers (in this case, the intermediate object) needs to get 
*immediate* notification when an object dies so as to prevent race 
conditions.

Anyhow, it seems that you're missing the point of what I wrote.  I think 
that SS sound really cool!  I would like to try them out!  But they are 
complex enough that they should not be a mandatory part of the language. 
  They should be implemented in a library for now.  Years later, if 
after long experience with it in a library, we all agree that it should 
be part of the next generation language, then we'll do it then.

Russ

Georg Wrede wrote:
 In article <cor3q6$1ls$1 digitaldaemon.com>, Russ Lewis says...
 
Georg Wrede wrote:


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


 
 I take it that you have connected all sending objects with delegates
 to all those interested in their signals? Thus, 100 sending objects
 emitting 10 different signals, and 100 receiving objects, each 
 interested in all of them, gives 100*100*10 = 100_000 connections.
 Additionally, using delegates, every sending object would "know" 
 the recipient?
 
 If all signals are sent via SS Dispatch, then we'd have
 100*10 + 10*100 = 2000 connections, only 2% of the former.
 
 If the pointers in SS Dispatch are not reference counted, then
 SS objects should signal it from their destructor. A semaphore
 in the Dispatch table could guarantee that the destructor does
 not return before same-time signals have returned.
 
 BTW, the Dispatch is only interested in signal receiving objects.
 
 
doable, but again, it's complexity better left to an (optional) library.


 
 I agree that new things should be made library, and only later
 considered for inclusion into the language. But I can't figure out
 how you could end up with a convenient syntax for SS then. Example:
 
 #   // (C++ from QT)
 #   class Foo : public QObject
 #   {
 #       Q_OBJECT
 #   public:
 #       Foo();
 #       int value() const { return val; }
 #   public slots:
 #       void setValue( int );
 #   signals:
 #       void valueChanged( int );
 #   private:
 #       int val;
 #   };
 #
 
 Of course, one could always run the code through a preprocessor,
 but that would be against the spirit of D, right?
 
 
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.


 
 Hmm. This suggests that (if not else, then for Asserts to be possible)
 you can ask the GC how many references currently point to an object.
 Like when you think there's only one reference to an object and it
 turns out there are 5.

Dec 04 2004

↑ ↓ ← → Georg Wrede <Georg_member pathlink.com> writes:

In article <cot4qh$2soj$1 digitaldaemon.com>, Russ Lewis says...
Anyhow, it seems that you're missing the point of what I wrote.  I think 
that SS sound really cool!  I would like to try them out!  But they are 
complex enough that they should not be a mandatory part of the language. 

They should be implemented in a library for now.  Years later, if 
after long experience with it in a library, we all agree that it should 
be part of the next generation language, then we'll do it then.


What can I say, I'm getting convinced!

Somehow this reminds me of the times everyone did their own linked lists
and trees again and again. It sure took a long time for mainstream 
languages to render that daily chore obsolete.

Actually, the only thing why I thought they should be in the language
core was to get a nice syntax. But on second thought that is a minor
issue.

Dec 07 2004

↑ ↓ ← → pragma <pragma_member pathlink.com> writes:

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

Dec 02 2004

↑ ↓ ← → Bastiaan Veelo <Bastiaan.N.Veelo ntnu.no> writes:

Thanks, Pragma, for the introduction :-)

The status is that signals and slots as defined by dcouple are currently 
usable in single-threaded applications. The declaration of signals is a 
tad more verbose than for example Trolltech's Qt framework, but that is 
just syntactic sugar. Connecting/disconnecting them looks actually nicer 
as compared to Qt, and since signals and slots get connected more often 
than declared, we are not too far off.

I should clean up the code a bit, because there are some work-arounds in 
there for compiler limitations that have since been fixed. On the 
todo-list are thread-safety, for which I see no problems. I am also 
interested in benchmarks against C++ implementations.

The big hindrance I see before we can call dcouple a state-of-the-art 
signal and slots implementation, is run-time identification of signals 
and slots in dynamically loaded classes. This is necessary for visual 
GUI designers/builders. Other properties in the classes will also need 
this kind of RTTI. This still needs some thinking, and possibly 
extension of the D language.

A language feature that has been discussed before, called "structed 
classes" (thread "Dropping the distinction between objects and 
references may hinder performance", started 10/18/04 23:12), if it ever 
gets implemented, would take away a good deal of the current complexity 
of dcouple, and improve performance.

By all means, check out dcouple and share your thoughts!
http://svn.dsource.org/svn/projects/dcouple/trunk/managed/doc/index.html

Bastiaan.


pragma wrote:
 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

Dec 04 2004

↑ ↓ ← → "Ben Hinkle" <ben.hinkle gmail.com> writes:

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


Delegates come close but they only fire a single callback instead of 
allowing multiple callbacks. This thread got me thinking about multicast 
delegates (ala C#) so I whipped up another chunk of D code to manage 
multiple delegates. Here's the example from the supplied Qt page modified to 
use multi-delegates, with output:
  class Foo {
    MultiDelegate!(int) valueChanged;
    private int val;
    int value() {
      return val;
    }
    void value(int v) {
      if (val != v) {
        val = v;
        valueChanged(v);
      }
    }
  }

  import std.stdio;
  int main() {
    Foo a = new Foo;
    Foo b = new Foo;
    a.valueChanged ~= &b.value;
    writefln(a.value," ",b.value);
    b.value = 11;
    writefln(a.value," ",b.value);
    a.value = 79;
    writefln(a.value," ",b.value);
    a.valueChanged.remove(&b.value);
    a.value = 100;
    writefln(a.value," ",b.value);
    return 0;
  }

output:

C:\d>dmd multidg.d -version=MultiDgExample
C:\dmd\bin\..\..\dm\bin\link.exe multidg,,,user32+kernel32/noi;

C:\d>multidg
0 0
0 11
79 79
100 79

It's probably almost the same as other implementations only I use dynamic 
arrays instead of associative arrays since:
1) dynamic array take up less space and are faster and most multi-delegates 
will have 1 or 2 delegates attached
2) the order of execution of the delegates matches the order in which they 
were attached.

anyhow, enjoy!

-Ben

Dec 04 2004

↑ ↓ ← → Georg Wrede <Georg_member pathlink.com> writes:

In article <cosich$255j$1 digitaldaemon.com>, Ben Hinkle says...
"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?



C:\d>dmd multidg.d -version=MultiDgExample
C:\dmd\bin\..\..\dm\bin\link.exe multidg,,,user32+kernel32/noi;

C:\d>multidg
0 0
0 11
79 79
100 79

It's probably almost the same as other implementations only I use dynamic 
arrays instead of associative arrays since:
1) dynamic array take up less space and are faster and most multi-delegates 
will have 1 or 2 delegates attached
2) the order of execution of the delegates matches the order in which they 
were attached.

anyhow, enjoy!

-Ben


Cool code! I'll use this.

Dec 07 2004

↑ ↓ ← → Bastiaan Veelo <Bastiaan.N.Veelo ntnu.no> writes:

Dr.Dizel wrote:
 In article <conii3$tkv$1 digitaldaemon.com>, Georg Wrede says...
 
How hard would it be to have signals&slots included in the D spec?


 
 Hi!
 Walter is in trouble because he has two "twins" in D: function pointers and
 delegates. He doesn't know what to do with them. He doesn't understand S&S
well,
 they OOP-ish and power. There is must be delegates and S&S instead of function
 pointers and delegates. But Walter still love C too much... shame! He froze any
 move in this way.
 :-(
 
 


Sorry Dizel, you must be trolling.

Dec 09 2004

↑ ↓ ← → John Reimer <brk_6502 yahoo.com> writes:

Dr.Dizel wrote:

 In article <conii3$tkv$1 digitaldaemon.com>, Georg Wrede says...
How hard would it be to have signals&slots included in the D spec?


 Hi!
 Walter is in trouble because he has two "twins" in D: function pointers
 and delegates. He doesn't know what to do with them. He doesn't understand
 S&S well, they OOP-ish and power. There is must be delegates and S&S
 instead of function pointers and delegates. But Walter still love C too
 much... shame! He froze any move in this way.
 :-(


Function pointers are still very useful for interfacing with C projects. 
They serve a different purpose than delegates.  I think you're hacking away
at a straw man.

Dec 09 2004