[phobos] Improving std.signals

[Sean Kelly]

What are the limitations of this for multithreaded use and reentrancy?  Can I modify the handler list from within a handler, etc?

Sent from my iPhone

On Oct 7, 2010, at 10:39 AM, Johannes Pfau <johannespfau at googlemail.com> wrote:

> 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
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos