Right. But is there anything one loses by not relying on it, by making the API more generic?
On Dec 30, 2010, at 7:58 , Jonas Sicking wrote: > On Wed, Dec 29, 2010 at 2:44 PM, Axel Rauschmayer <[email protected]> wrote: >> Can someone explain a bit more about the motivation behind the current >> design of the async API? >> >>> var request = window.indexedDB.open(...); >>> request.onsuccess = function(event) { ... }; >> >> 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? >> >> Maybe it is just me, but I would like it better if the last argument was an >> object with the error and the success continuations (they could also be >> individual arguments). That is also how current JavaScript RPC APIs are >> designed, resulting in a familiar look. Are there any arguments *against* >> this approach? >> >> Whatever the reasoning behind the design, I think it should be explained in >> the spec, because the current API is a bit tricky to understand for newbies. > > Note that almost everyone relies on this anyway. I bet that almost all > code out there depends on that the code in for example onload handlers > for XHR requests run after the current thread of execution has fully > finished. > > Asynchronous events isn't something specific to javascript. > > / Jonas > -- Dr. Axel Rauschmayer [email protected] http://hypergraphs.de/ ### Hyena: organize your ideas, free at hypergraphs.de/hyena/
