On Wed, Sep 21, 2011 at 6:14 PM, Eric U <[email protected]> wrote: > If we eliminate it entirely, then you can't ever start a new read on > the same object from the abort handler. That seems like a reasonable > use case. >
It's trivial to stuff it into a zero-second timeout to knock it out of the event handler. This is such a common and useful pattern that libraries have shorthand for it, eg. Prototype's Function#defer. I don't think that's an onerous requirement at all; it's basically the same as specs saying "queue an event". Adding a number-of-reads-outstanding counter isn't that much more > code. It's not much more code, but it's code dealing with a case that doesn't have to exist, working around a very ugly and unobvious sequence of events, and it's something that you really shouldn't have to worry about every single time you use loadstart/loadend pairs. And if you're really trying to keep things simple, you're not > aborting and then starting another read during the abort, so the above > code works in your app. > The above code and the code triggering the reads might not even be written by the same people--the activity display might be a third-party component (who very well might not have thought of this; I wouldn't have, before this discussion). -- Glenn Maynard
