>> There's only one variation that's standard, and every browser is or >> will soon be implementing that one. > > How can you said so? isn’t every Promise library pass A+ test considered > standard?
There is a specific variation of promises in the ECMAScript standard which is compatible with promises/a+. Passing the tests simply means your implementation of promises is compatible. >> Continuations are a different concept, and don't address what we were >> trying to solve when adopting promises. > > Yes, they’re different, i would like to know what is promise solved but they > didn’t address ? > >> Those languages often also have Promises, or Futures, or Tasks, or one >> of the other closely-related names and concepts. > > They have, but that’s totally different because they use lightweight thread. > Future in haskell is just a MVar. If the filesystem API in node.js starts to use promises then it would be using a background thread, just as it is doing for callbacks at the moment. >> On Oct 1, 2015, at 8:25 AM, Tab Atkins Jr. <[email protected]> wrote: >> >>> On Wed, Sep 30, 2015 at 5:18 PM, 韩冬 <[email protected]> wrote: >>> Yes, i understand it’s too late to revise Promise design, my random thought >>> are: >>> >>> 1. Why we put Promise into language? >> >> Because it exposes useful functionality. I recommend reading some of >> the Promise explainers that exist for lots of examples. >> >>> Promise are complex state machine, there can be so many variations, each >>> implementation have different performance characteristic, which one should >>> be built into language? >> >> There's only one variation that's standard, and every browser is or >> will soon be implementing that one. >> >> The "state machine" isn't complex. "unresolved" goes to either >> "resolved to another promise", "fulfilled", or "rejected". "resolved >> to another promise" eventually turns into "fulfilled" or "rejected". >> Or, of course, hangs, which "unresolved" can also do. >> >>> 2. Why we don’t look for continuation based implementation at the first >>> place? >> >> Continuations are a different concept, and don't address what we were >> trying to solve when adopting promises. >> >>> Lisp, haskell or even some transpiled to js language like elm use >>> continuation solve callbacks already, why didn’t port them? >>> Now we invent a complex state machine based solution, a lot of people will >>> creating them everytime using an `async` without understand the cost. >> >> Those languages often also have Promises, or Futures, or Tasks, or one >> of the other closely-related names and concepts. >> >> ~TJ > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
