Killing `Promise.fulfill`

Mark S. Miller erights at google.com
Mon Aug 19 18:34:09 PDT 2013


On Mon, Aug 19, 2013 at 6:20 PM, Mark S. Miller <erights at google.com> wrote:

> 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.
>

To clarify, the status quo is that recursive unwrapping happens on both the
output side of .then and in Promise.resolve. Moving it to the input side of
.then is exactly as useful, is almost exactly compatible, and does the
complicated thing in one place rather than two. Even without adding
.flatMap, this is a good idea anyway.



>
> 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 gmail.com> 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 mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130819/3237604e/attachment.html>


More information about the es-discuss mailing list