On Dec 29, 2010, at 2:44 PM, Axel Rauschmayer wrote:
> The pattern of assigning the success continuation after invoking the
> operation seems to be to closely tied to JavaScript’s current
> run-to-completion event handling. But what about future JavaScript
> environments, e.g. a multi-threaded Node.js with IndexedDB built in or Rhino
> with IndexedDB running in parallel? Wouldn’t a reliance on run-to-completion
> unnecessarily limit future developments?
As a long-time member of the ECMAScript standardization effort, I usually avoid
making predictions about the future of JS, but I feel pretty confident
predicting that the language is not going to evolve to support pre-emptive,
shared-memory threading. See e.g. Brendan Eich's blog post from a few years ago:
http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html
I don't think you need to worry about JS acquiring pre-emption semantics. We
*are* working on standardizing generators, which are a sort of explicit
pre-emption mechanism; in that case a programmer might write:
var request = window.indexedDB.open(...);
yield; // relinquish control...
request.onsuccess = function(event) { ... }; // oops, too late
but arguably that's not such a big deal since the programmer has explicitly
done the assignment after yielding control.
All that said, I agree with you that the API design requiring the programmer to
assign listeners mutably, rather than being able to use the more functional
approach, is clunky.
Dave
