Domenic Denicola domenic at domenicdenicola.com
Fri Apr 26 12:43:57 PDT 2013

From: Kevin Smith [zenparsing at gmail.com]

>>> Yes, sorry. It will on version 1.1: https://github.com/promises-aplus/promises-spec/#the-promise-resolution-procedure

>> To clarify: in 1.0, the behavior of returning a thenable was highly underspecified, in part because of a lack of clarity about promises vs. thenables. In 1.1, returning a thenable is now specified in the same detail as the rest of the spec, and (of course) has accompanying tests.

> Ah - thanks for the info.  But as far as I know, you can't test the case where a promise's value is actually a promise, because Q doesn't support that feature.  True?


> The difference would only surface when testing that case.

Not quite. You can still have thenables that call `onFulfilled` with another thenable, to any depth. You can also insert a real promise at the end of any-length thenable chain. A simple test case would be

const a = { then(onFulfilled) { onFulfilled(b); } };
const b = { then(onFulfilled) { onFulfilled(5); } };

adapter.fulfilled() // a real Q promise, via `Q.resolve()`.
  .then(function () {
    return a;
  .then(function (value) {
    assert.strictEqual(value, 5); // note: `5`, not `b` (and of course not `a`).

I am also considering adding optional test cases for libraries that do expose a non-resolve fulfill, which Q would not partake in but e.g. DOMFuture could.

More information about the es-discuss mailing list