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

On Fri, Apr 26, 2013 at 3:20 PM, David Sheets <kosmo.zb@gmail.com> wrote:
>> 2013/4/26 Kevin Smith <zenparsing@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@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.

Gah! This, of course, should read:

If onFulfilled *returns* a "promise", that value is returned. If
onFulfilled *returns* a normal value, that value is lifted into a
promise and returned. If onFulfilled *returns* 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

Received on Friday, 26 April 2013 14:25:59 UTC