Killing `Promise.fulfill`

Mark S. Miller erights at
Mon Aug 19 18:20:30 PDT 2013

Let's separate two forms of complexity:

a) Complexity visible to those who must use, implement, or understand the
full API including .flatMap.

b) Complexity visible to those who only use, implement, or understand the
subset without .flatMap.

The main beauty of AP2 is that it minimizes the complexity of #b. My
hypothesis and hope is that #b has the same complexity as a Promises/A+
compatible promise proposal would be without flatMap. If adding flatMap
support increases the complexity of #b, that would be bad. Do you see any
way in which it does?

Note that #b differs from "a Promises/A+ compatible promise proposal would
be without flatMap" in one substantive way: Moving the recursive
unwrapping/flattening/assimilation to the input side of .then. As already
discussed on the Promises/A+ list, this should be close to compatible with
Promises/A+ code, as the difference is only visible when the behavior of
recursive unwrapping is side-effect-dependent. Also, it should make things *
simpler*, as the "resolve" operation (or whatever it would be called) would
no longer need to do the recursive unwrapping. By putting recursive
unwrapping on the input side of .then, it need not appear anywhere else.

Assuming TC39 declares consensus on AP2, I expect Promises/A+ to move the
recursive unwrapping to the .then input, or to at least allow it, so that
TC39 and DOM promises remain compatible with Promises/A+. Likewise with Q.
I don't expect either Promises/A+ or Q to ever provide .flatMap.

I leave it to the DOM folks to evaluate whether the subset they need soon
needs to include .flatMap.

On Mon, Aug 19, 2013 at 5:11 PM, Kevin Smith <zenparsing at> wrote:

> With all the changes to Promise (addition of Promise#flatMap, recursive
>> unwrap on input side of Promise#then, etc.), it does seem that fulfill's
>> use case has become a bit muddled. I'll admit to still being partial to the
>> earlier design (fulfill/resolve/reject, adopt without recursive
>> unwrap/flattening) as it was a much simpler and more straightforward API.
> I tend to agree.
> { Kevin }
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list