Re: Deprecating Future's .then()

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

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 Monday, 3 June 2013 21:00:54 UTC