From: Kevin Smith [[email protected]]
>>> 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?
Correct.
> 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
```js
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`).
done();
});
```
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.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
