Perhaps the unwrapping behavior of .then could be specified as an optional
argument in the Promise constructor and .resolve methods. The default behavior
is the current standard (i.e. .then auto-unwraps), but a different behavior
could be specified:
```
var unwrapPromise1 = Promise.resolve(1);
var unwrapPromise2 = Promise.resolve(unwrapPromise);
unwrapPromise2.then(value => {
assert(value === 1); // unwraps
})
var flatPromise1 = Promise.resolve(1, "flat"); // or some other indicator of a
monadic promise
var flatPromise2 = Promise.resolve(flatPromise1, "flat");
flatPromise2.then(value => {
assert(value === flatPromise1);
})
var mixedPromise = unwrapPromise2.then(value => flatPromise2);
mixedPromise.then(value => {
assert(value === flatPromise1); // mixedPromise's unwrapping stops at
flatPromise1 as it starts to unwrap flatPromise2 but stops unwrapping due to
the defined behavior.
return value;
}).then(value => {
assert(value === flatPromise1); // Since the previous .then was unwrapped
into a "flat" promise, chained .then calls remain "flat".
});
```
Basically, unwrapping of .then stops once the monadic behavior is reached.
This would work for Promise.all/Promise.race as well since they could respect
this behavior. This has the added benefit of specifying Promises with a
minimal API surface that auto-unwrap for ES6, but add optional arguments to the
constructor and .resolve for ES7 or later to specify this behavior. As far as
the Promise consumer is concerned, when they use .then, they will get the
result the Promise producer expects them to get (the final underlying value in
the common use case, or a possible promise in the monadic case). The API
surface area does not change, and monadic promises become an opt-in for those
that need the specialized case.
Best regards,
Ron
> -----Original Message-----
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Brendan Eich
> Sent: Wednesday, February 5, 2014 7:46 AM
> To: Quildreen Motta
> Cc: Mark S. Miller; EcmaScript
> Subject: Re: Promise.cast and Promise.resolve
>
> Quildreen Motta wrote:
> > but as with other parts of JavaScript, the simpler, orthogonal
> > primitives are not available for users to derive more complex
> > functionality from easily.
>
> So true. JS is like a mini-toolkit of three-tool Swiss Army Knife
> (functions) with constructor and closure tools as well as the big first-class
> function edged tool; and super-caulk (objects) usable in a pinch as adhesive
> as well as sealant. Kind of what you want when you are traveling light, in a
> hurry running from zombies, no time to get a proper toolbox.
>
> Part of TC39's work has been decomposing some of the multi-tools into new
> forms that do one thing well (arrow functions are my favorite in this regard).
> But it is both hard to justify the effort, and actually a lot of effort, to
> decompose fully in all cases.
>
> Still I agree with Paolo. If we had functional (even value-like, featureless,
> then-able only via a special form, as in E) Futures, we could rebuild Promises
> on them and let Promises remain the library they've always been.
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
