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