W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: Deprecating Future's .then()

From: Sam Tobin-Hochstadt <samth@ccs.neu.edu>
Date: Tue, 4 Jun 2013 03:55:44 -0400
Message-ID: <CAK=HD+ZrSckduZizJDiZp8RMaMTR8+osKM+_1E5WqbWxpPkefw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, "Mark S. Miller" <erights@google.com>, Sean Hogan <shogun70@westnet.com.au>, "www-dom@w3.org" <www-dom@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Alex Russell <slightlyoff@google.com>
On Mon, Jun 3, 2013 at 5:00 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Jun 3, 2013 at 11:21 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Mon, Jun 3, 2013 at 3:13 PM, Mark S. Miller <erights@google.com> wrote:
>>> Me too. I find your points about why AP2 (recursive unwrapping of callback
>>> argument) is superior to AP3 (recursive unwrapping of callback result)
>>> persuasive.
>> Interesting, how would that work?
> 1. Promises have both unconditional lift (Future.accept/fulfill) and
> conditional lift (Future.resolve).

Thinking about this more, I'm now unsure why both `fulfill` and
`resolve` are needed given the semantics of `.chain()` and `.then()`
described below.

In particular, if `.then()` chains recursively *before* calling the
callback, then there's no difference between:

    Future.resolve(x).then(v => ...)


    Future.fulfill(x).then(v => ...)

even when `x` is a promise.  The only way to observe this is with `.chain()`.



> 2. If you register a .then() callback, and the promise resolves to
> another promise, it will move the callbacks down to the inner promise;
> this continues until it finally resolves to a non-promise value, at
> which point the callbacks are called.  If the callback returns a
> non-promise value, the chained promise fulfills to that; if it returns
> a promise, the chained promise adopts its state in a non-recursive
> manner, fulfilling directly to the same value as the returned promise.
> 3. Promises sprout another method, called .chain() or .flatMap() or
> something, that doesn't do these bits of magic.  It calls its
> callbacks as soon as the promise fulfills, regardless of what type of
> value it fulfills to.  The callback return value must be a promise
> (rejecting the chained promise with a TypeError if not, I suppose),
> and the chained promise adopts its state.
> Done!  This allows both methods of promise manipulation (promises as
> flow control, and promises as containers) to transparently
> interoperate arbitrarily, so consumers can choose at every point in
> the chain whether they want to fully flatten or just get the immediate
> inner value.  You never have to choose one method as "canonical" and
> break anything that wants to use the other method.
> ~TJ
Received on Tuesday, 4 June 2013 07:56:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:02 UTC