Promises Consensus with /A+ terminology

Mark Miller erights at gmail.com
Fri Aug 2 14:42:26 PDT 2013


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
> volunteers?
>
> 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
mandates.

On the others, tc39 consensus promises should follow promises/A+.




> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130802/f31864a7/attachment.html>


More information about the es-discuss mailing list