Re: Deprecating Future's .then()

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

and

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

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

Thoughts?

Sam

> 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