W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

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

From: David Sheets <kosmo.zb@gmail.com>
Date: Fri, 26 Apr 2013 15:20:16 +0100
Message-ID: <CAAWM5TzCqRjGZB0-95cUSG6z__fQ0bQ3QMHGZhOhVxhwHZVBWg@mail.gmail.com>
To: Juan Ignacio Dopazo <dopazo.juan@gmail.com>
Cc: Kevin Smith <zenparsing@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
> 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.

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:20:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC