A Challenge Problem for Promise Designers (was: Re: Futures)

David Sheets kosmo.zb at gmail.com
Fri Apr 26 07:20:16 PDT 2013


> 2013/4/26 Kevin Smith <zenparsing at gmail.com>
>>
>> What exactly is the controversy here?

I believe the controversy is over the number of resolution iterations
for a given wrapped value.

>> I think we all agree with the semantics of "then" as specified in
>> Promises/A+.  (If not, then we have a really big problem!)

I believe the semantics of "then" refer to the semantics of
[[Resolve]] in Promises/A+. The controversy, as far as I can tell, is
over whether [[Resolve]].2.3.1 at
<https://github.com/promises-aplus/promises-spec> should read:

If/when resolvePromise is called with a value y, run [[Resolve]](promise, y).

OR

If/when resolvePromise is called with a value y, fulfill promise with y.

On Fri, Apr 26, 2013 at 2:43 PM, Juan Ignacio Dopazo
<dopazo.juan at gmail.com> wrote:
> Promise/A+ does not prohibit promises for promises. But in practice the
> problem is recognizing what is a promise. There are two options:
>
> 1) Recognize all thenables as promises
> 2) Recognize only the promises from your own library
>
> Many implementations go with (1), including ODMFuture. Since it doesn't
> distinguish between promises and thenables, then() flattens all of them.

This does not appear to be the behavior specified in Promises/A+ as
far as I can tell.

If onFulfilled is called with a "promise", that value is returned. If
onFulfilled is called with a normal value, that value is lifted into a
promise and returned. If onFulfilled is called with a non-promise
"thenable", the "thenable" is chained *and then re-resolved* per
2.3.1.

It is this recursive re-resolution which is up for debate.

PRO:

Re-resolution prevents confusing nesting

CON:

Re-resolution causes confusing recursive behavior

In the common case (no nesting), both above versions of 2.3.1 behave
identically. In the exceptional case, the non-recursive version is
easier to reason about because the resolution doesn't strip away all
your thenables.

>From my reading, DOM Futures doesn't state anything about resolution
semantics, to its detriment, but abstracts those semantics behind
FutureResolver.

Have I presented this correctly? Why is it a problem to specify a
single level of assimilation instead of sometimes-flattening
"thenables" but never flattening promises?

Have I missed something?

Thanks,

David


More information about the es-discuss mailing list