Now take a look at even a very simple Promise library Q form its design document: https://github.com/kriskowal/q/blob/v1/design/q7.js <https://github.com/kriskowal/q/blob/v1/design/q7.js>
> 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. With all these state transition added, it’s quiet complex to me to figure out how does it work, i have to go back and read the design process from 1 to 7. Should we expect future js programmers just use it, or understand it before use it? ~winter > On Oct 1, 2015, at 8:25 AM, Tab Atkins Jr. <[email protected] > <mailto:[email protected]>> wrote: > > On Wed, Sep 30, 2015 at 5:18 PM, 韩冬 <[email protected] > <mailto:[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
