Alternative to Promise
forbes at lindesay.co.uk
Sun Oct 4 10:55:38 UTC 2015
There are no problems with reusability that I can think of as a result of the internal state machine. The functions passed to `.then` are just plain functions, so they are perfectly reusable.
I don't think there is a significant overhead to promises once properly optimised. I don't see how your solution would lead to lower overhead.
By contrast, systems built without a carefully engineered state machine (e.g. Thunks and your continuation based system) tend to lead to race conditions in user land code. Once people try and write parallel code or caching/memoised using lazy continuation based systems they quickly end up needing to convert them into some kind of eager data structure. This is often done badly (it's very difficult to get right) and can lead to very hard to debug race conditions. By contrast, promises are very carefully designed and tested implementations of exactly this functionality.
From: 韩冬 <handong05 at meituan.com<mailto:handong05 at meituan.com>>
Sent: Saturday, October 3, 2015 1:04 p.m.
Subject: Re: Alternative to Promise
To: Benjamin Gruenbaum <benjamingr at gmail.com<mailto:benjamingr at gmail.com>>
Cc: <es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>>
Here is my summary:
* Pros for state machine based solutions:
* Auto memorization.
* Easy sementics.
* Cons for state machine based solutions:
* Bad reusability.
* Larger overhead.
* Pros for continuation based solutions:
* Good reusability, since continuation are just functions.
* Lower overhead.
* Cons for continuation based solutions:
* Complex sementics.
* No memorization(can be done by other ways).
Thanks again for giving me lots of detail about the history, now i need more : )
On Oct 1, 2015, at 4:42 PM, Benjamin Gruenbaum < benjamingr at gmail.com<mailto:benjamingr at gmail.com>> wrote:
> Where do you get the courage to challenge every inventor that they have to learn everything you've learned before they making decisions?
Can we please keep it civil?
> the question is why not check other languages first, when there’re nice solutions already there.
Promises are rooted in the 1980s and have been pretty much adopted in every mainstream programming language one way or another:
- Task - C#
- Future - Scala
- Deferred - Python
- CompletableFuture - Java
- Future - C++
There are about 3 years of discussions to read about the choices and the rationale for why promises behave exactly the way they behave and you're welcome to read those on the specific choices.
If you're interested in current proposals for other async primitives for the language - there is currently an observable proposal and an async iterator proposal - both solve different issues than promises (multiple values over push/pull) and are currently in design stages.
In general, the list frowns upon people who "plug their library" in the list - so I suggest that in the future you start your email with the specific problem you want to address and what you do differently. The more concise you write (and external links aren't that great for this) the better chance you'll get more responses from people involved.
Cheers and good luck,
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss