(v1.0) Postpone coercion to time-of-use #372
Conversation
Regarding #369 Among other things, if Q wraps a thenable, this postpones coercion until the consumer attempts to use the promise. Before, `Q(thenable)` would call `thenable.then` as soon as possible, but now the user must go all the way to `Q(thenable).then()` in order for `thenable.then()` to be invoked. This is less surprising in principle. This is achived by adding an "accepted" state to deferred promises, between "pending" and "resolved". This state is reflected by `deferred.promise.inspect()`. This change breaks many specs, which need to be reviewed and probably fixed.
|
I dislike exposing accepted as a state. Unfortunately I am not sure I know of a way around it. Perhaps inspect() could trigger the unwrapping process? But no, access to untrusted "then" methods must be done in a fresh stack, so that would never be useful. Sigh. It definitely complicates the pedagogical story. |
|
I believe @erights may want to review these changes and contemplate the implications. |
|
At the .then-level, which is the level Q and Promises/A+ operate at (in contrast to the lower .flatMap-level of the full AP2 proposal on es-discuss), we still don't need to distinguish AP2's adoption from acceptance, so I would avoid the term "accepted". Rather, if promise p is resolved to promise q, then p follows q. The question is, how to describe the state where p is resolved to a non-promise v, where we don't yet even know whether v will be considered thenable. In this case, at the AP2 .flatMap-level p can only accept v, since only promises can be adopted. Nevertheless, at our .then-level, I think the right concept to extend is "following" as in p follows v. So a promise can follow anything. But once p.then happens, in a later turn we further resolve p according to v's state and behavior. As Domenic says, as long as v might be a thenable, "fulfilled" and "rejected" are no longer concrete states, but rather expository states to explain how p's behavior depends on v's. Regarding the Q-specific inspection methods, I doubt there is any perfect way to maintain compatibility with their old behavior. So let's start by asking: What are these used for? |
|
@erights Debugging, testing, and optimizing are the uses today. It is also the polymorphic basis for implementing methods like |
|
I should clarify. |
|
What would happen if we withdrew all of these for a while and then added them, or something like them, back in as we encounter concrete use cases that need them? |
|
I would be content to dump
|
|
These are the affected tests if we stretch |
|
If we promote acceptance to adoption at time of resolution if the accepted value is a branded promise, the fallout drops somewhat. At the end of the day, I would not mind dumping |
|
This question clarified something for me regarding thenables and memoization. With apologies to Albert, I propose that "Thenables should be assimilated as late as possible, but no later." Once p.then(v => .., e =>..) fires, from then on it remains fulfilled or rejected to whatever it provided as the callback argument. In particular, if v later becomes a thenable, this will not affect the behavior of p itself. A later p.then will still report p as fulfilled with v itself. Or, with apologies to post-Albert, observing p's settlement (by being invoked as a callback by p.then) causes the collapse of p's assimilation function. |
|
I’ll leave it to our resident Caltech physicist to put to record whether the uncertainty metaphor applies as well as it sounds! |
|
I asked my cat and she says "well, yes and no." |
|
lol! The memoization plan makes sense to me, as does the analogy :). Sigh, now to spec all this... |
|
BTW @kriskowal would love your feedback on https://github.com/domenic/promises-unwrapping, which tries to capture this late-unwrapping shift. It still needs memoization work though. |
See related discussions in kriskowal/q#372.
Implement the `Promise` constructor. The promise constructor serves both as a deferred promise constructor that accepts a function, and a new kind of promise constructor that accepts a backing handler object. The backing handler object must implement `dispatch(resolve, op, operands)` and `inspect()`. The new promise constructor replaces the `Q.promise` function, which is deprecated. The new promise constructor replaces `makePromise`, which has been removed entirely. As such, Q-Connection will have to be rearchitected to provide a custom promise handler for remote objects instead of using `makePromise`. Fixes #346. Postpone calling `then` on a thenable until a message is dispatched to the coerced promise. Fixes #372. When coercing a thenable, memoize the resulting promise to avoid re-starting a lazy promise. Add support for vicious cycle detection. Fixes #223. This change request also reviews the Q API, deprecating many interfaces that remain from legacy designs. Fixes #215. Factor most Node.js tools into `q/node` module. Mirror deprecated interfaces in Q. Support for `close` and `closed` has been removed from `Queue`, which has additional ramifications for Q-Connection. I intend to use Q-IO streams in Q-Connection instead of raw queues. Most of the Q specifications continue to work after these changes, but with many deprecation warnings. The specs have been revised to appease the deprecation warnings. :warning: However, the specifications for "progress" have all been disabled pending a closer investigation to decide whether to fix Q or fix the specs. The promise protocol no longer supports "set" and "delete" operations. Function application is a special case of "post", and for support of "fbind", it is now possible to pass a "thisp" as a final argument. The "when" message is now called simply "then". Support for pre-ECMAScript 5 has been abandoned outright, pending review. Removed: - Q.set, promise.set - Q.delete, promise.delete - Q.nearer - Q.master The following methods of `Q` are deprecated in favor of their equivalents on the `promise` prototype: - `progress`, `thenResolve`, `thenReject`, `isPending`, `isFulfilled`, `isRejected`, `dispatch`, `get`, `post`, `invoke`, `keys` Other deprecations: - Q.resolve in favor of Q - Q.fulfill in favor of Q - Q.isPromiseAlike in favor of Q.isThenable - Q.when in favor of Q().then - Q.fail and promise.fail in favor of promise.catch - Q.fin and promise.fin in favor of promise.finally - Q.mapply and promise.mapply in favor of promise.post - Q.send and promise.send in favor of promise.invoke - Q.mcall and promise.mcall in favor of promise.invoke - Q.promise in favor of new Q.Promise with a resolver function - Q.makePromise in favor of new Q.Promise with a handler object - promise.fbind in favor of Q.fbind - deferred.makeNodeResolver() in favor of require("q/node").makeNodeResolver(deferred.resolve) - promise.passByCopy() in favor of Q.passByCopy(promise), provisionally Node.js wrappers that have been moved into their own module have a deprecated interface in Q proper: - `nodeify`, `denodify`, `nfbind`, `nbind`, `npost`, `ninvoke` But the following experimental aliases are deprecated and do not exist in `q/node`: - `nsend` for `ninvoke` - `nmcall` for `ninvoke` - `nmapply` for `npost`
Implement the `Promise` constructor. The promise constructor serves both as a deferred promise constructor that accepts a function, and a new kind of promise constructor that accepts a backing handler object. The backing handler object must implement `dispatch(resolve, op, operands)` and `inspect()`. The new promise constructor replaces the `Q.promise` function, which is deprecated. The new promise constructor replaces `makePromise`, which has been removed entirely. As such, Q-Connection will have to be rearchitected to provide a custom promise handler for remote objects instead of using `makePromise`. Fixes #346. Postpone calling `then` on a thenable until a message is dispatched to the coerced promise. Fixes #372. Fixes #369. When coercing a thenable, memoize the resulting promise to avoid re-starting a lazy promise. Add support for vicious cycle detection. Fixes #223. This change request also reviews the Q API, deprecating many interfaces that remain from legacy designs. Fixes #215. Factor most Node.js tools into `q/node` module. Mirror deprecated interfaces in Q. Support for `close` and `closed` has been removed from `Queue`, which has additional ramifications for Q-Connection. I intend to use Q-IO streams in Q-Connection instead of raw queues. Most of the Q specifications continue to work after these changes, but with many deprecation warnings. The specs have been revised to appease the deprecation warnings. :warning: However, the specifications for "progress" have all been disabled pending a closer investigation to decide whether to fix Q or fix the specs. The promise protocol no longer supports "set" and "delete" operations. Function application is a special case of "post", and for support of "fbind", it is now possible to pass a "thisp" as a final argument. The "when" message is now called simply "then". Support for pre-ECMAScript 5 has been abandoned outright, pending review. Removed: - Q.set, promise.set - Q.delete, promise.delete - Q.nearer - Q.master The following methods of `Q` are deprecated in favor of their equivalents on the `promise` prototype: - `progress`, `thenResolve`, `thenReject`, `isPending`, `isFulfilled`, `isRejected`, `dispatch`, `get`, `post`, `invoke`, `keys` Other deprecations: - Q.resolve in favor of Q - Q.fulfill in favor of Q - Q.isPromiseAlike in favor of Q.isThenable - Q.when in favor of Q().then - Q.fail and promise.fail in favor of promise.catch - Q.fin and promise.fin in favor of promise.finally - Q.mapply and promise.mapply in favor of promise.post - Q.send and promise.send in favor of promise.invoke - Q.mcall and promise.mcall in favor of promise.invoke - Q.promise in favor of new Q.Promise with a resolver function - Q.makePromise in favor of new Q.Promise with a handler object - promise.fbind in favor of Q.fbind - deferred.makeNodeResolver() in favor of require("q/node").makeNodeResolver(deferred.resolve) - promise.passByCopy() in favor of Q.passByCopy(promise), provisionally Node.js wrappers that have been moved into their own module have a deprecated interface in Q proper: - `nodeify`, `denodify`, `nfbind`, `nbind`, `npost`, `ninvoke` But the following experimental aliases are deprecated and do not exist in `q/node`: - `nsend` for `ninvoke` - `nmcall` for `ninvoke` - `nmapply` for `npost`
Regarding #369
Among other things, if Q wraps a thenable, this postpones coercion until
the consumer attempts to use the promise. Before,
Q(thenable)wouldcall
thenable.thenas soon as possible, but now the user must go allthe way to
Q(thenable).then()in order forthenable.then()to beinvoked. This is less surprising in principle.
This is achived by adding an "accepted" state to deferred promises,
between "pending" and "resolved". This state is reflected by
deferred.promise.inspect().This change breaks many specs, which need to be reviewed and probably
fixed.