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.
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.
Why would it deprecate the promised wrapper?
I have pointed out in #152 reason why I do like promised wrapper and why I proposed it for inclusion to Q.
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.
This would deprecate the promised wrapper because then nfbind would become equivalent to promised.
doesn't it make fbind equivalent to promised? since nfbind also adds a callback function. Good point though.
Right yes, that's definitely what I meant.
I'm definitely 👍 for this then.
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.
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.