[phobos] Improving std.signals

[Andrei Alexandrescu]

Hi Johannes,


The code looks very promising. Could you please generate documentation 
from it and make a proposal to digitalmars.d?


Andrei

On 9/29/10 9:16 AM, Johannes Pfau wrote:
>   Hi,
> I needed signals for a simple test program some time ago and because I
> wanted to learn D templates anyway I coded my own signal implementation.
> I then saw phobos already had an implementation of signals and slot in
> std.signals, but I was kinda disappointed by the implementation in
> std.signals. D offers the possibilities to enhance it in many ways.
>
> The limitations of std.signals:
> *Only supports delegates, not even functions. And it should also support
> objects/structs with opCall
> *Only supports delegates of class objects.
> The std.signal implementation attaches a DisposeEvent to the object of
> the delegate. This only works for classes. It first sounds like a good
> idea to automatically remove the delegate when the object is destroyed,
> but: explicit delete is deprecated; the garbage collector should not
> collect the object while the delegate is still registered; it limits
> delegate support to class delegates; requiring the user to explicitly
> remove the delegate is ok. Most(all?) signal implementations require
> explicitly removing the signal handlers.
> *Delegates return void. Most signal implementations have handlers return
> bool. When a handler returns false, the remaining handlers are not called.
> *Uses template mixins. Template structs work as well and give a nicer
> syntax.
>
> So I merged my signals implementation with std.signals. All problems
> mentioned above have been fixed. I additionally added the following things:
> *Support all handlers with void or bool return type. Using bool return
> type is preferred though, because it's faster.
> *Overloads for += and -= like in C#
>
> I also came up with a pretty nice use case for structs with opCall:
> Consider this common c# code:
> public delegate void ChangedEventHandler(object sender, EventArgs e);
> The sender object is part of the Signal type. Now, this won't work for
> D, because structs aren't objects and signals can be at module level as
> well.
> But the struct + opcall support allows us to do this in a even better way:
> struct Handler
> {
>      object _sender;
>      bool opCall(string s)
>      {
>           //use _sender and s
>      }
>      this(object sender)
>      {
>          this._sender = sender;
>      }
> }
> obj.onDatareceived.connect(new Handler(obj));
>
> Using this technique we can pass any number of additional arguments.
> This could also be used to build an signal->message passing dispatcher:
> obj.onDatareceived.connect(new EventMessage!string(tid));
>
> I then looked into the glib api documentation to see what additional
> functionality it's signal handling offers.
> It's basically:
>   * Handler IDs.
> this would allow us to add the same handler to a signal multiple times.
> It also makes addafter/before easier, but it's not required for that.
> I wonder whether phobos already has something like an IDPool, something
> like this: http://ideone.com/xs80c
>   * block/unblock complete signal (easy to do)
>   * block/unblock handlers (shouldn't be too hard)
>   * threading? (Is this useful/ needed?)
>   * addafter / before (Adding handlers before a specific handler)
>   * is handler connected? (easy)
>   * stop signal emission (only useful when used with threading)
>
> If the new code was accepted into phobos, I'd offer to implement the
> features above as well, if desired.
>
> The proposed new std.signals code is located here:
> http://ideone.com/NHS5C
>