W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Promises: Auto-assimilating thenables returned by .then() callbacks: yay/nay?

From: Mark S. Miller <erights@google.com>
Date: Thu, 2 May 2013 13:51:57 -0700
Message-ID: <CABHxS9hTVWpHrsfUHRVBn9NUEZMv5vZdwVt0N22TCkNoi1AkMw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Thu, May 2, 2013 at 1:27 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, May 2, 2013 at 12:55 PM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
> > From: Tab Atkins Jr. [jackalmage@gmail.com]
> >> While I clear that up (since the naming and the behavior are not
> inconsistent, which is extremely confusing),
> >
> > This isn't really true. The `acceptCallback` is the callback called when
> the promise is fulfilled ("accepted" in the DOMFuture promise library). It
> uses `resolve` semantics to process its return values, but it would need to
> do that anyway, in order to get different behavior for promises and for
> values. You need to distinguish between the condition on which the callback
> is called, and the behavior of the callback with respect to its return
> values.
>
> Yes, the first callback to .then() needs to use resolve semantics, so
> you can return either a plain value or a future.  Right now, though,
> "resolve semantics" means "recursively flatten nested futures until
> you end up with a single future holding a plain value".
>
> I thought I'd gotten several people, including you and Mark Miller, to
> acknowledge that recursive flattening was not necessary for native
> promises,


Recursive flattening is not necessary, possible, or meaningful for
promises, since we've carefully avoided introducing an explicit
unconditional lift operator which would enable the creation of a
promise-for-promise. Since DOMFutures are apparently proceeding on their
own, prior to achieving any consensus at TC39, promises will view
DOMFutures simply as thenables and assimilate them recursively when it
encounters them.

As for whether DOMFutures flatten, unwrap, or assimilate promises, I leave
that to you, since it seems we have no choice but to leave that to you
anyway. I find it a terrible shame that we were not able to repair this
forking of our efforts.




> only non-native promise-likes ("thenables").  If necessary,
> I can go dig up the exact email from you where you said that the
> use-case for recursive flattening was assimilation, and it wasn't
> necessary to automatically do so for native promises.
>
> >> can you comment on the rest of my message?
> >
> > There's not much to say. I think assimilating thenables is good, for
> reasons that have been discussed at length before. You disagree. I have a
> hard time seeing what else you'd find helpful from me.
>
> What I'm hoping for is an explanation of why assimilating thenables is
> necessary in the .then() callbacks, and why my concerns about
> predictability (such as returning an object which has a .then()
> method, but is not a promise-like, which "assimilates" with
> non-sensical behavior and possibly causes errors) are either unfounded
> or less important than the benefits of auto-assimilation.
>
> To be clear, I'm *completely for* assimilation, just via an explicit
> function call.
>
> ~TJ
>
>


-- 
    Cheers,
    --MarkM
Received on Thursday, 2 May 2013 20:52:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC