RE: Deprecating Future's .then()

On Tue, Jun 4, 2013 at 9:48 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Jun 4, 2013 at 8:55 AM, Sam Tobin-Hochstadt <samth@ccs.neu.edu> wrote:
>> 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?
>
> I'm just going to try to repeat what you said here to make sure I understand.
>
> Promise.resolve(val) creates a promise of val, regardless of whether
> val is a promise, has a callable then property, or anything like that.
> (In that sense it is equivalent to Future.accept() today.)
>
> promise.then() keeps unwrapping promise's internal value until it no
> longer has a callable then property at which point it invokes the
> relevant callback passed to promise.then(). (Exact algorithm TBD after
> broader agreement.)
>
> promise.chain() invokes its relevant callback with promise's internal value.
>
> promise.then() and promise.chain() return value (newPromise) is
> resolved with the return value of their callbacks after it has been
> unwrapped once.

In general, this approach is extremely interesting. The shift from focusing on promise fulfillment and being in the three states of pending, fulfilled, and rejected to focusing on promise resolution and being in the two "fates" of unresolved and resolved is a big difference. But it is probably a win as it ends up eliminating the state concept almost entirely, making it just an emergent way of describing what happens with `then`.

One point I am not entirely clear on is why there is *any* unwrapping of return values, as in the last step Anne describes. For consumption with `then` it seems to make no difference. I assume this is to match flatMap or bind semantics from other languages, so that if you use `chain` exclusively you match Haskell/Scala/et al. semantics?

I also think the name "chain" is pretty confusing, especially in light of already-existing terminology around promise chaining [1]. Is there precedence for it in other languages? flatMap seems clearest to me so far.

[1]: https://www.google.com/search?q=promise+chaining

Received on Tuesday, 4 June 2013 14:35:33 UTC