Promises Consensus with /A+ terminology
Mark S. Miller
erights at google.com
Fri Aug 2 14:47:58 PDT 2013
On Fri, Aug 2, 2013 at 2:42 PM, Mark Miller <erights at gmail.com> wrote:
> On Fri, Aug 2, 2013 at 2:28 PM, Domenic Denicola <
> domenic at domenicdenicola.com> wrote:
>> From: Mark S. Miller [erights at google.com]
>> > A good start would be to convert
>> https://github.com/promises-aplus/promises-tests to test262 form,
>> extending test262 in the process in order to accommodate async testing. Any
>> If someone does the latter (preferably with a simple Mocha-like `done()`
>> facility), I will happily do the former. I imagine there might be licensing
>> issues with non-Ecma members; would that still be the case for code
>> licensed under the WTFPL?
> Damn. I'm glad you raised this. Yes, there are issues. I don't know what
> they are. Would someone more knowledgeable of this minefield like to
> answer? Thanks.
>> The only divergence between DOM promises and Promises/A+ so far are:
>> 1. The handling of non-`undefined`, non-function arguments, which
>> Promises/A+ mandates must be ignored while DOM Promises mandate must throw
>> a synchronous `TypeError`. (This is a spec bug; it should result in an
>> asynchronous `TypeError` rejection.)
>> 2. DOM Promises requires `onFulfilled` and `onRejected` to be called as
>> if they were methods of the promise itself, whereas Promises/A+ requires
>> they be called as functions.
>> 3. DOM Promises mandates an infinite loop for the code `const q =
>> fulfilledPromise.then(() => fulfilledPromise)`, whereas Promises/A+
>> mandates that `q` be rejected with a `TypeError`.
>> 4. DOM Promises mandates an infinite loop for the code `const q1 =
>> fulfilledPromise.then(() => q2); const q2 = fulfilledPromise.then(() =>
>> q1)`, whereas Promises/A+ allows (but does not require) that
>> implementations reject `q1` and `q2` with a `TypeError`.
>> Of these, 1 I am ambivalent on, 2 I think was a very strange mistake, and
>> 3 and 4 feel like oversights. But none of them are a big deal.
> I think tc39 quick consensus promises should not gratuitously differ from
> promises/A+, i.e., they should only differ when there's a well motivated
> reason, as with the addition of .flatMap and the shift of recursive
> flattening from the output side of .then to the input side.
> On #1, I like your parenthetical variant on DOM promise behavior (async
> rejection) better than either what promises/A+ does or what DOM currently
I retract this. Although I would like it better, it is not worth diverging
from promises/A+ on this one. Let's stick to promises/A+ except where it
really matters (.flatMap and recursive unwrapping on input side)
> On the others, tc39 consensus promises should follow promises/A+.
>> es-discuss mailing list
>> es-discuss at mozilla.org
> Text by me above is hereby placed in the public domain
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss