domenic at domenicdenicola.com (2013-11-17T17:44:17.675Z)
Yes. The only immediate correctness constraint needed in ES6 and the immediate DOM timeframe is the "empty stack" requirement Stated at https://github.com/domenic/promises-unwrapping#coercethenablethenable-then as > 4. Assert: the execution context stack is empty. Stated at https://github.com/promises-aplus/promises-spec#the-then-method as > 4. onFulfilled or onRejected must not be called until the execution context stack contains only platform code. [3.1]. citing https://github.com/promises-aplus/promises-spec#notes stating: > 1. Here "platform code" means engine, environment, and promise implementation code. In practice, this requirement ensures that onFulfilled and onRejected execute asynchronously, after the event loop turn in which then is called, and with a fresh stack. This can be implemented with either a "macro-task" mechanism such as setTimeout or setImmediate, or with a "micro-task" mechanism such as MutationObserver or process.nextTick. Since the promise implementation is considered platform code, it may itself contain a task-scheduling queue or "trampoline" in which the handlers are called. Some of the underlying issues this addresses are explained at the https://github.com/promises-aplus/promises-spec/issues/139 thread and the previous issue threads it cites.
Yes. The only immediate correctness constraint needed in ES6 and the immediate DOM timeframe is the "empty stack" requirement Stated at < https://github.com/domenic/promises-unwrapping#coercethenablethenable-then> as "4. Assert: the execution context stack is empty." Stated at <https://github.com/promises-aplus/promises-spec#the-then-method> as "4. onFulfilled or onRejected must not be called until the execution context stack contains only platform code. [3.1]." citing <https://github.com/promises-aplus/promises-spec#notes> stating: '1. Here "platform code" means engine, environment, and promise implementation code. In practice, this requirement ensures that onFulfilled and onRejected execute asynchronously, after the event loop turn in which then is called, and with a fresh stack. This can be implemented with either a "macro-task" mechanism such as setTimeout or setImmediate, or with a "micro-task" mechanism such as MutationObserver or process.nextTick. Since the promise implementation is considered platform code, it may itself contain a task-scheduling queue or "trampoline" in which the handlers are called.' Some of the underlying issues this addresses are explained at the < https://github.com/promises-aplus/promises-spec/issues/139> thread and the previous issue threads it cites. On Thu, Oct 3, 2013 at 10:41 AM, Yusuke SUZUKI <yusukesuzuki at chromium.org>wrote: > Thu, Oct 3, 2013 at 11:43 PM, Alex Russell <slightlyoff at google.com> wrote: > >> Only that a suitable hook is needed that embedders can implement. Luckily >> that's simple WRT existing semantics (we are oblivious to future turns at >> the language level) and doesn't demand that we import the event loop itself >> into the language. The only requirement is that promises are async WRT the >> calling code. Delivery at the end of the current turn is allowed. >> Object.observe will require that we define an order, but until then, hand >> waving is sufficient. >> > > Make sense. So microtasks won't be introduced yet, but Promises and > asynchronous execution semantics (enough for Promises) are introduced into > ES6. Is it correct? > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131003/3d05390b/attachment.html>