>From what I can tell std.signal is designed around the idea that an
entire class acts as a signal emitter, without the ability to write multiple signals within one class and making arbitrary connections between signals and slots.

If you actually read the full paper it links to: http://www.elpauer.org/stuff/a_deeper_look_at_signals_and_slots.pdf

you'll see that the idea of signals and slots is to avoid writing specialized signal classes, and instead just use member functions as signal emitters.

I don't see why we can't have something as good or even better than Qt's and Boost's signals and slots implementations. I admit I haven't had a look at the other implementations linked from the std.signals page yet, so maybe there's some better implementations out there. But from a current standpoint it looks to me like std.signal is a good candidate for a revamp.

Andrej Mitrovic wrote:
>>From what I can tell std.signal is designed around the idea that an
>entire class acts as a signal emitter, without the ability to write multiple signals within one class and making arbitrary connections between signals and slots.
>
>If you actually read the full paper it links to: http://www.elpauer.org/stuff/a_deeper_look_at_signals_and_slots.pdf
>
>you'll see that the idea of signals and slots is to avoid writing specialized signal classes, and instead just use member functions as signal emitters.
>
>I don't see why we can't have something as good or even better than Qt's and Boost's signals and slots implementations. I admit I haven't had a look at the other implementations linked from the std.signals page yet, so maybe there's some better implementations out there. But from a current standpoint it looks to me like std.signal is a good candidate for a revamp.

I started a std.signal rewrite ~1 year ago: This is what I came up
with:
http://dl.dropbox.com/u/24218791/d/src/signals.html
https://gist.github.com/1194497

I think the API isn't too bad, but the internal implementation could be improved. I didn't know about boost.signals, so that could be used to improve my implementation.

However, I think it's useless as long as it can't be used by multiple threads. But when I wanted to add 'shared' support to it, I always hit a dead end, a bug, something not working, so in the end I gave up.

Another point which could be improved is that it currently only works for @safe/@trusted delegates. Maybe a @system signal is also useful. And I'm also not sure how (or whether) signals are meant to be integrated with message passing.

-- 
Johannes Pfau

On 04/09/2011 22:27, Andrej Mitrovic wrote:
> From what I can tell std.signal is designed around the idea that an
> entire class acts as a signal emitter, without the ability to write
> multiple signals within one class and making arbitrary connections
> between signals and slots.

I for one was surprised when I looked at it a while ago and found it doesn't seem to support multiple signals per class. I'm no expert but I'm used to GTK+ named signals and expected something comparable.

== Quote from Nick Treleaven (nospam@example.com)'s article
> On 04/09/2011 22:27, Andrej Mitrovic wrote:
> > From what I can tell std.signal is designed around the idea that an entire class acts as a signal emitter, without the ability to write multiple signals within one class and making arbitrary connections between signals and slots.
> I for one was surprised when I looked at it a while ago and found it doesn't seem to support multiple signals per class. I'm no expert but I'm used to GTK+ named signals and expected something comparable.

You can have multiple signals per class by naming the mixins:

class Send
{
  void fire()
  {
    sigA.emit("A", 1);
    sigB.emit("B", 2);
  }

  mixin Signal!(string, int) sigA;
  mixin Signal!(string, int) sigB;
}

class Watch
{
   void watchA(string, int) { /// Do stuff }
   void watchB(string, int) { /// Do stuff }
}

Send s = new Send;
Watch w = new Watch;

s.sigA.connect(&w.watchA);
s.sigB.connect(&w.watchB);

s.fire();

Unless I am misunderstanding this thread?

Cheers,
Cal

On 9/5/11, Cal <callumenator@gmail.com> wrote:
> You can have multiple signals per class by naming the mixins:

Seems like you're right. I completely missed this in the docs. I think I could make a pull to add another example of multiple signals, I didn't know they were supported.

I sure hope that code is well tested though. Does anyone know why calloc/realloc are used inside of connect() instead of letting the GC do its thing?

Well it seems I can't use this with freeform delegates that are not class fields. This could definitely use some improvement.

On 9/5/11, Johannes Pfau <spam@example.com> wrote:
> I started a std.signal rewrite ~1 year ago: This is what I came up
> with:
> http://dl.dropbox.com/u/24218791/d/src/signals.html
> https://gist.github.com/1194497

This actually works great for me since it supports lambdas, I've tried it and it works. I'll put my sample up on the cairoDSamples repo once it's done. Thanks for this!

Andrej Mitrovic wrote:
>Well it seems I can't use this with freeform delegates that are not class fields. This could definitely use some improvement.

You're talking about phobos std.signals, not my implementation, right? Last time I asked on the mailing list I was told that std.signals was written in the D1 days and not updated since then.

The reason why this only works with class delegates: std.signals looks up the class a delegate belongs to and registers a callback in druntime to get notified when the object gets destroyed. This seems only useful with explicit delete, which is now deprecated.

-- 
Johannes Pfau

Andrej Mitrovic wrote:
>On 9/5/11, Johannes Pfau <spam@example.com> wrote:
>> I started a std.signal rewrite ~1 year ago: This is what I came up
>> with:
>> http://dl.dropbox.com/u/24218791/d/src/signals.html
>> https://gist.github.com/1194497
>
>This actually works great for me since it supports lambdas, I've tried it and it works. I'll put my sample up on the cairoDSamples repo once it's done. Thanks for this!

I'm glad it's useful for you. Please note that the disconnect method might not work correctly until http://d.puremagic.com/issues/show_bug.cgi?id=5011 is fixed. (At least one unittest also fails because of that)

-- 
Johannes Pfau