- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 1 May 2013 09:15:45 -0700
- To: Alex Russell <slightlyoff@google.com>
- Cc: Claus Reinke <claus.reinke@talk21.com>, es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Anne van Kesteren <annevk@annevk.nl>
On Wed, May 1, 2013 at 9:07 AM, Alex Russell <slightlyoff@google.com> wrote: > On Wednesday, May 1, 2013, Tab Atkins Jr. wrote: >> On Tue, Apr 30, 2013 at 9:43 AM, Claus Reinke <claus.reinke@talk21.com> >> wrote: >> > The promises-aplus spec has a note that confuses me >> > >> > https://github.com/promises-aplus/promises-spec#notes >> > >> > 1. In practical terms, an implementation must use a mechanism such >> > as >> > setTimeout, setImmediate, or process.nextTick to ensure that >> > onFulfilled >> > and onRejected are not invoked in the same turn of the event loop as >> > the >> > call to then to which they are passed. >> > >> > I have not yet been able to decide whether DOMFuture has a >> > similar provision, or how this note is meant to be interpreted. >> >> Juan already pointed out the "queue a task" language, so this is answered. > > > This is far too glib. The spec may very well be wrong on this point. The > design goal isn't to require a full yeild of the event loop, but instead to > force async code flow -- that means that resolving and calling back should > be able to happen at "end of microtask"; the same timing as Object.observe() > callbacks. Possibly true, but those are details. The context of my response was someone asking about whether DOMFutures described asynchrony *at all*. The spec does mandate asynchrony, even if it might be the wrong kind of asynchrony. ^_^ ~TJ
Received on Wednesday, 1 May 2013 16:16:32 UTC