Tab Atkins Jr. wrote:
On Tue, Feb 4, 2014 at 10:55 AM, Rick Waldron<waldron.r...@gmail.com> wrote:> Per Resolution > (https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-30.md#conclusionresolution-3) > > - Promise.cast is renamed to Promise.resolve (remove old Promise.resolve) > - Keep then, reject chain (NOT DEFER, reject!) > - Renaming .cast thus removes over-wrapping (always-wrap) deoptimization in > old Promise.resolveOkay, so this is discarding the previous consensus, right? Monadic promises are thrown out?
Fundamental conflict between .chain and .then, on three levels:1. Committee "do both" / union proposals smell and bloat -- this is a problem _per se_.
2. All the standard combinators call .then not .chain.3. Including .chain requires always-wrapping resolve, observability trumps optimizability.
There's really a 0 implicit in this: 0. Monadic vs. non-monadic is an exclusive or -- you can't "have it all".
This breaks async maps forever, then. :/ With the previous consensus, the result promise from an async map could be observed directly with .chain(), and it worked great regardless of what was stored inside the map. With only flat promises, if you store a promise in an async map and then try to retrieve it later, the error callback gets called if the key wasn't in the map*or* the key was in the map, but the stored value was a rejected promise. You have to spread your program logic over both callbacks to catch that case (or more likely, people will just write programs that break occasionally because they assumed that the reject branch of the AM.get() promise is only for failed lookups, as the documentation probably says).
This does seem like a problem in the async map API, but I bet it can be solved without taking the hit of 1-3 above. Overloading get's return value is the root of the evil. Hand-boxing disambiguates the r.v.
Similarly, if you store a forever-pending promise in the async map, it's impossible to ever retrieve it. Even just a long-pending promise will stall your program's logic while it waits, preventing you from updating UI when the map returns and*then* completing the operation when the stored promise finally resolves.
This, I don't buy. You have to hand-box using {value: } or whatever.
The only way to get a working async map is to defensively store your values in a single-element array (or some other non-promise wrapper object) and unwrap them on retrieval.
Right, hand-box. That's the price of the XOR between Monadic and anti-Monadic promises, and anti-monadic already won in the library evolution of Promises.
Pretending that all promises are identical identity-less wrappers that can be arbitrarily collapsed is such a mistake.>_<
There are no great paths forward. I would like to make promises value objects, E-like. But it's too late. Promises happened, the DOM and ES6 need them, worse is better. You knew that already!
/be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
