It is certainly a legitimate problem, and your solution has elegance going for it. My concern would be the performance overhead.
I do write functions with omittable parameters. But I also tend to limit myself to no more than three positional arguments before introducing an "options object" that takes the rest, unless performance is at a very serious premium (a function called in inner loops thousands of times, for instance). If I'm allowing omittable parameters, I tend to check arguments.length and make decisions on that basis at the top of a function, repopulating the named parameters of the function with the values "one parameter over" if necessary. In theory this can get complicated, but having many positional parameters is too complicated for the end user to remember anyway so I would never choose to introduce more than one or two optional parameters in the first place. (There are cases, again in tight loops, where more than three required, positional parameters are unavoidable for performance reasons.) On Sunday, October 5, 2014 1:25:14 PM UTC-4, Eyal Arubas wrote: > > I'm wondering what are some common ways to approach the problem of > figuring out which arguments the user has passed to a function. > > It's a problem I've encountered many times when writing libraries with > APIs; especially for functions with optional arguments. > Each such function requires logic to figure out which of the arguments > were supplied, and assign default values to those which weren't. > A function with just a few arguments requires a large chunk of code just > for this purpose. > > An alternative approach is to use an `options` object, the fields of which > represent the arguments, and directly assigned by the user. > This, however, imo, is less suitable for public APIs. I prefer to have > function signatures with distinct arguments. > > It seemed to me like there should be a programmatic solution to this. Each > function's arguments should hold certain conditions. Arguments must be of > certain types, some are optionals, some have default values, etc. > This led me to develop a module which allows to declare the properties of > the function's arguments. The module resolves tnd disambiguates the > arguments passed by the user based on those declarations. > > https://github.com/EyalAr/Decree > > Decree works by analyzing a list of argument declarations. It then figures > out all the possible combinations. > For example, a function which receives two arguments, with the first one > optional, has two possible combinations - the user can call the function > with one argument (thus omitting the first one), or with two (thus > providing the first one). > A function with two arguments, of which non is optional, has only one > combination. > When the user calls the function, decree will match the supplied arguments > to a certain combination. If no combination is found, the user supplied > invalid arguments. If more than one combination is found, the user was not > specific enough, and there is ambiguity. Decree can tell where is the > problem. > > How do you usually approach this problem? > And what do you think about this solution? > -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/55d11b56-4543-4e39-ba77-fe50d179e8bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
