Joshua N Pritikin wrote: >Sure, but is Event really the perfect API design that we should try to >implement perfectly? That would be an interesting discussion! What >does Event do wrong and what would a better design look like ... ?
I've already got some thoughts about a better design. I think the best way to approach that is first to document exactly what interface Event has, as I've suggested. That would make it easier to see which bits are awkward. (Example: the complicated interaction of "at", "after", "interval", and "repeat" options in creating timers. I'd make them more independent, to make them less likely to cause surprise.) However, the Event API is quite usable, and even if a complete revision is undertaken we should support users of Event. Correctly implementing the existing OK API should be independent of designing the new super-wonderful API. From the point of view from which I came to this discussion: I want to make serious use of Event *now*, not wait for a new one. What really needs to be done with the Event API is not necessarily to get the cleanest handling of async events but to make it possible to handle them somehow. The API just doesn't permit these events to be handled properly. If you are implacably opposed to making async events invisible, then you must provide a way to explicitly invoke asynccheck, so that it is possible to handle them correctly in cases where race conditions can be ruled out. As an Event user I'd be satisfied with that. >Event has its faults, but it _is_ optimized for speed. Are ->start and ->pending really speed-critical? I find that unlikely. Optimising for speed means optimising the things that get called the most, *not* absolutely everything. asynccheck itself is cheap. Do you have timing tests you can run to try out my proposed changes? >asyncCheck is only called where we can't avoid it, in one_event (and >sweep). Another approach: calling asynccheck when it's theoretically required can be *optional*, allowing the user to make the tradeoff between cleanliness and speed. The default should be to perform asyncchecks automatically, so that if the user does nothing special it all works, giving a really clean interface. If the user wants to get that little bit of extra speed, they can explicitly choose to accept the extra complication of having to be aware of when asynccheck runs. There would be an option on ->pending, ->start, one_event, sweep, and loop, to say "don't bother checking for async events"; it should also be possible to invoke asynccheck explicitly. -zefram
