RE: Futures

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?

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.

Received on Friday, 26 April 2013 19:44:28 UTC