W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

RE: Futures

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Fri, 26 Apr 2013 19:43:57 +0000
To: Kevin Smith <zenparsing@gmail.com>
CC: Juan Ignacio Dopazo <dopazo.juan@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, EcmaScript <es-discuss@mozilla.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F7EF5CBBE@BY2PRD0510MB354.namprd05.prod.outlook.com>
From: Kevin Smith [zenparsing@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.
Received on Friday, 26 April 2013 19:44:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC