Joshua N Pritikin wrote: >> +=item $source->active_watchers > >This is interesting. Do you really need this API?
Not in anything I'm currently doing, though I might end up using it for debugging. I added that API because it provides meaningful information and is easy to efficiently implement. I can imagine someone finding it very useful in the future. >Conceptually, I like the simplicity of being able to assume that the >#-of-watchers doesn't matter (ignoring the funny corner cases you found >with signals). Indeed. The main reason for me creating event source objects, rather than creating events directly on watchers, was so that the event creation would be independent of the number of watchers. >Even though the Event API is inconsistent and quirky, I would like to >strive for consistency where possible. You seem to be hinting that the ->active_watchers() interface is in some way inconsistent with this watcher-number independence. I don't see that it is. Its existence doesn't force the user to do anything in a way that is dependent on the number of watchers. It merely allows the user to extract state information that is already known to exist: the relation between the event source and its watchers is part of the architecture. If the user wants to trace the source<->watcher relation in that direction, I see no reason to prevent it. Can you explain in more detail what you're getting at? By the way, the information available from ->active_watchers() can already be obtained from other parts of the Event interface. The output of Event::all_watchers() could be filtered to obtain the same list, though by requiring the examination of all watchers this technique would be rather inefficient. -zefram
