More flexibility in the ECMAScript part?
bruant.d at gmail.com
Thu Apr 18 00:31:57 PDT 2013
Le 18/04/2013 05:07, Tab Atkins Jr. a écrit :
> On Wed, Apr 17, 2013 at 3:57 PM, Allen Wirfs-Brock
> <allen at wirfs-brock.com> wrote:
>> A a rule of thumb, if a library does something that can not be expressed in
>> the its base language there is a good chance it is extending "the virtual
>> machine" of the language and it should at least be reviewed from that
>> perspective and iframe semantics. These are both examples of browser design
>> choices that have deep semantics impact upon the language.
> Note that Futures are entirely expressible in today's JS semantics.
Allen was concerned about the "ECMAScript" definition of what you're
loosely calling "JS" while it seems you're referring to "web platform
Specifically, the current semantics uses "queue a task" which interacts
with the event loop which is part of the web platform, but not ECMAScript.
I've read intention to move the event loop from HTML Living Standard to
ECMAScript 7, but we're not there yet and that work is necessary before
adding promises to ECMAScript.
More information about the es-discuss