Promises Consensus with /A+ terminology

Domenic Denicola domenic at
Fri Aug 2 14:28:45 PDT 2013

From: Mark S. Miller [erights at]

> A good start would be to convert 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?

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.

More information about the es-discuss mailing list