- From: David Herman <dherman@mozilla.com>
- Date: Mon, 3 Jan 2011 10:18:45 -0800
- To: Axel Rauschmayer <axel@rauschma.de>
- Cc: public-webapps@w3.org
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
Received on Monday, 3 January 2011 21:26:51 UTC