Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider promisify treatment of multiple arguments #34

Open
medikoo opened this issue Sep 4, 2014 · 3 comments
Open

Reconsider promisify treatment of multiple arguments #34

medikoo opened this issue Sep 4, 2014 · 3 comments
Assignees
Milestone

Comments

@medikoo
Copy link
Owner

medikoo commented Sep 4, 2014

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.

@medikoo medikoo self-assigned this Sep 4, 2014
@medikoo
Copy link
Owner Author

medikoo commented Nov 20, 2015

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 error
    • resolveResult: function (arg1, arg2...) { ... } Custom arguments mapper, it will allow to map list of arguments to convinent form custom way, e.g. in case of Request we may make resolved result as { req: req, res: res }

@nejucomo
Copy link

nejucomo commented May 27, 2016

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.

@medikoo medikoo added this to the v1 milestone May 27, 2016
@medikoo
Copy link
Owner Author

medikoo commented May 27, 2016

@nejucomo thanks for comment, this one definitely will be addressed and will be published with v1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants