[phobos] Improving std.signals

[Johannes Pfau]

 I'm sorry it took me so long to respond, it has been a busy week ;-)

On 30.09.2010 17:21, Robert Jacques wrote:
> Hi Johannes,
> The signals code base, as far as I know, hasn't been updated since the
> D1 days, so I'm glad someone is looking at it. I can't really comment
> on the implementation itself, since I'm not a user of signals, but
> there is an API issue I'd like to point out. I consider operator
> overload abuse, particularly of the "+" for concatenation kind,
> verboten in D. In fact, we have "~" as a dedicated concatenation
> operator specifically to avoid this issue. I'd recommend changing the
> "+=" function to "~=" and dropping "-=". 
OK, I've done that. I just adopted the syntax from C#, but yeah ~= fits
better into D signals. And ~= overloading can be used with pointers (+=
can't) so ~= is definitely the only choice in this case.
> Also, although I don't use signals, I have used DFL's events which are
> very similar. One of my major grips about them was the inability to
> use std.algorithm, etc., to modify the underlying array of delegates.
> Since signals is really a specialized container, I would strongly
> recommend adding support for ranges and containers to it. For example,
> I may want to add my new handler before all the existing handlers,
> which I can't do currently using connect.
I'm not sure about that. I changed the internal implementation from an
array to std.containers SList now, so just publishing the range
interface is easy. But Signal internally only stores delegates. There's
no way to get the original representation of the handler(function, class
with opCall) from the delegate. So publishing forward ranges of these
delegates isn't that useful. To make it useful, I'd have to make
getDelegate public, but I fear that would break encapsulation as
getDelegate is an implementation detail. On the other hand the range
interface could be quite useful so I'm not really sure what to do about
that.

I also dropped the idea of handler ids, so the only way to refer to an
handler is the function address / delegate / object / that was used to
register the handler. This simplifies the implementation and also saves
some runtime memory. The only limitation this causes is that the same
handler can be connected only once per signal, but I don't think that's
a problem.

I will implement some more features (is handler registered, ...) and
post the updated code on the weekend.

-- 
Johannes Pfau