Alternative to Promise

[韩冬]

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. <jackalmage at gmail.com <mailto:jackalmage at gmail.com>> wrote:
> 
> On Wed, Sep 30, 2015 at 5:18 PM, 韩冬 <handong05 at meituan.com <mailto:handong05 at meituan.com>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151001/06ed1d83/attachment-0001.html>