Promises

Mikeal Rogers mikeal.rogers at gmail.com
Tue Nov 6 12:33:51 PST 2012


On Nov 6, 2012, at November 6, 201211:35 AM, Rick Waldron <waldron.rick at 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 <bruant.d at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121106/4ee72313/attachment.html>


More information about the es-discuss mailing list