Promises Consensus

Mark S. Miller erights at google.com
Thu Aug 1 11:04:00 PDT 2013


Between Tab's answer and mine, we see the two issues one might mean by
"branding". Anne's clarifying summary at
https://mail.mozilla.org/pipermail/es-discuss/2013-August/032465.htmlspeaks
only in terms of "promise-likes". One of the things we need to
settle is whether there is one predicate that applies to all the places in
this summary that says "if ... promise-like". IMO we need to distinct tests
-- 

* isPromise for whether p is a promise and
* isThenable for whether p is thenable.

I would have the output-side tests for both .flatMap and .then be
isPromise. I would also have the input side test for .then use isThenable.
.flatMap has no input-side test, which is its point. A somewhat separable
question is what these two tests are testing.

The first hard reason why we must at least have an isPromise test on the
output side of .then is that the promise already returned by .then must
adopt this output promise without calling its .then method. Otherwise we
lose support for lazy evaluation and for promise pipelining.

If the output side of .then is a non-promise thenable, it is a separate
question whether it should be "adopted" by calling its .then method or
whether it should be accepted. IMO it should be accepted. The isThenable
test indicates something ugly is going on -- assimilation. With this AP2
based design, we can isolate this ugliness to the input side of .then.

The second reason why the two tests need to be separate is that the output
side of .flatMap cannot adopt simply by calling the output's .then method,
because otherwise you'd often get exactly the recursive unwrapping that
.flatMap is trying to avoid. In order to avoid this, it must test whether
there is anything it can do to adopt other than calling .then.


On Thu, Aug 1, 2013 at 10:43 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Thu, Aug 1, 2013 at 10:33 AM, Juan Ignacio Dopazo
> <dopazo.juan at gmail.com> wrote:
> > If then() deep flattens, flatMap() only flattens one level and promises
> > assimilate thenables, is branding really necessary?
>
> The concept of "thenable" *is* branding.  It's just branding with a
> short, simple string property ("then"), rather than branding with a
> hard-to-collide string (like __promiseBrand__ or something) or a
> symbol.
>
> ~TJ
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



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


More information about the es-discuss mailing list