A Challenge Problem for Promise Designers (was: Re: Futures)
kosmo.zb at gmail.com
Fri Apr 26 07:24:23 PDT 2013
On Fri, Apr 26, 2013 at 3:20 PM, David Sheets <kosmo.zb at gmail.com> wrote:
>> 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).
> 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
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
> It is this recursive re-resolution which is up for debate.
> Re-resolution prevents confusing nesting
> 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
> 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?
More information about the es-discuss