On Nov 6, 2012, at November 6, 201211:35 AM, Rick Waldron 
<waldron.r...@gmail.com> wrote:

> Based on a read through of https://github.com/promises-aplus/promises-spec, 
> these things initially come to mind, please regard as a loose collection of 
> varying thoughts that may or may not be completely relevant:
> 
> 1. The definition of a "promise" is really just a plain object or function 
> with an expando property, I would think that a language level addition would 
> require its own standard built-in object: Promise, which when invoked as a 
> constructor initializes a new promise object which has a "then" method... 
> Domenic has it covered from there.

also, node.js won't adopt either a promise "API" or a promise syntax for it's 
core API. if it lands in the language then nothing is stopping people from 
using it but the ecosystem is highly unlikely to adopt it either since it's not 
uniform across node.

we've had great success using function (err, result) {} across core and across 
the ecosystem, it's been widely successful as you can see by the number of 
modules created, the breath of functionality those modules provide, and their 
seamless compatibility with each other.

> 
> 2. The notes describe some excellent practical implementation points, but 
> none of them are actually part of the ECMAScript standard, eg. setTimeout, 
> process.nextTick. Should these be specified or left unspecified? 
> Object.observe describes delivery as "Schedule change events to be delivered 
> asynchronously 'at the end of the turn'", which is not very specific.
> 
> 3. Does this belong in the language or would it make more sense to exist as a 
> "standard module"?
> 
> 
> Rick
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Nov 6, 2012 at 2:15 PM, David Bruant <bruan...@gmail.com> wrote:
> Le 06/11/2012 20:07, Axel Rauschmayer a écrit :
>> That’s at a weird intersection between HTML5 and ECMAScript, (...)
> I think it's more historical than anything. The event loop, 
> setTimeout/Interval (and promises) belong to the language (ECMAScript), not 
> to a library (HTML5) in my opinion.
> ECMAScript 1-5 were concurrency-neutral. A pure ES5 programs has a start and 
> an end and that's it. No concurrency whatsoever.
> ES6 is going in that direction too.
> ES7 opens a breach to event loop concurrency with async observers 
> (object.observe)
> 
> David
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to