Implicitly resolve arguments before dispatching messages #160

kriskowal opened this Issue Dec 29, 2012 · 8 comments


None yet
4 participants

kriskowal commented Dec 29, 2012

For further consideration. This has performance implications and introduces chat hazards for communicating with remote promises.

When dispatching messages to promises, convert all arguments to fulfilled values before sending the message.

Credit goes to @Gozala for requesting this ages ago.

From #152

This would deprecate the promised wrapper.

This would necessitate the introduction of a means for wrapping a promise such that when immediately fulfills with the promise itself, for situations where you deliberately wish to pass the promise as an argument, such as with a remote object. This might be addressed by my idea to add push and pull to promises for explicitly sending values, particularly wrapped functions, up and down a Q connection.


ForbesLindesay commented Jan 2, 2013

Why would it deprecate the promised wrapper?


Gozala commented Jan 2, 2013

I have pointed out in #152 reason why I do like promised wrapper and why I proposed it for inclusion to Q.
#152 (comment)

I have not took q-comm into consideration, mainly because remote promises feel special anyway. Either way I won't be too broken hearted if this will go away since Q API surface has grown enough for me not to be comfortable using it.


domenic commented Jan 4, 2013

This would deprecate the promised wrapper because then nfbind would become equivalent to promised.


ForbesLindesay commented Jan 7, 2013

doesn't it make fbind equivalent to promised? since nfbind also adds a callback function. Good point though.


domenic commented Jan 7, 2013

Right yes, that's definitely what I meant.


ForbesLindesay commented Jan 7, 2013

I'm definitely 👍 for this then.


domenic commented Jul 9, 2013

This has back-compat implications not only for how it changes the meaning of code that currently passes promises around but also because, as we noted above, we'd remove Q.promised.


kriskowal commented Oct 20, 2013

The negative impact I expect from this is that a remote invocation passing a remote promise would wait a full round trip before delivering the invocation message. This case is probably enough of a reason to close this issue.

This one case is enough that I’m convinced I do not even have to ask @erights whether this is a bad idea. Summarily, closing.

kriskowal closed this Oct 20, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment