Joshua N Pritikin wrote: >The embarrassing inconsistency is that the other watcher types do not >offer this API. Signal watchers could easily offer this API. However, >it doesn't make much sense for io, timers, or idle watchers.
This is because the other watcher types don't have reified event sources. (This is a method on the event source, not the watcher.) Other than generic watchers, signal and var watchers come the closest to having reified event sources. I think an API that lists all the active watchers of a variable would be feasible and similarly useful for debugging. >> By the way, the information available from ->active_watchers() can >> already be obtained from other parts of the Event interface. ... > >Correct, which is another reason not to add ->active_watchers(). Strange: I see it as a reason in favour of the API. It's not changing the architecture by making any new information available, so is safe to add in that respect. It has a huge efficiency advantage when implemented by Event itself rather than the user, which is a very good reason to implement it this way if we intend the functionality to be possible. I see it as most important for a library interface to be consistent and orthogonal in the information model it presents to users, rather than in the actual function interfaces. In the realm of extracting information that is definitely available to the user, it is a good idea to blanket the conceptual space, providing the same information in whichever ways it can be efficiently provided in order to save the user the trouble of massaging it in complicated ways. -zefram
