Reconsider promisify treatment of multiple arguments
medikoo opened this issue · 3 comments
Problem well discussed here: petkaantonov/bluebird#307
In short: non-breaking change to external API may result in breaking change for module that relies on promisify
, that certainly raises the issue.
Proposal:
- By default always promisify first argument after error as resolved value, that's it
- Support options argument to promisify, with which we could alter how resolved value is prepared:
mulitpleResult: true
When provided, each call will resolve with an array that would contain all arguments after errorresolveResult: function (arg1, arg2...) { ... }
Custom arguments mapper, it will allow to map list of arguments to convinent form custom way, e.g. in case ofRequest
we may make resolved result as{ req: req, res: res }
I'm new to node, but familiar with Twisted's deferred (from python), and after a quick skim of this README this looks like the library I want. However, the very first node call I tried to promisify
was child_process.execFile
which is a multi-arg callback api: callback(error, stdout, stderr)
. I just wanted to point this out so that once a solution is implemented, the docs could use execFile
as an example.
FWIW, I prefer the {multipleResult: true}
API design, and dislike any kind of automatic coercion logic like:
if (arguments.length > 1) {
/* use an array */
} else {
/* use arguments[0] */
}
-because this introduces a type ambiguity: It prevents writing a generic callback that tries to distinguish these two cases, because arguments[0]
may itself be an Array
.