Tom, Performance is indeed a concern. For each declaration of arguments a function is built by the module (one time). This function is called every time we need to determine the arguments the user passed. Part of the operation of this function is to try to match the user's arguments to some valid combination of arguments. This can be more costly than the regular `if-else` boilerplate code.
I haven't done any benchmarks yet, so I can't say what's the impact on performance, if any. I agree that more than three optional arguments is not very common, but it's not very rare in my experience. With 3 optional arguments, the regular boilerplate code of `if-else` statements and `arg2 = arg2 || arg1` is a nuisance, but manageable. With 4, it's a real headache. It's grunt work, and as such, I wanted a way to automate it and make it simpler for the programmer to focus on writing the function itself; as well as for others reading the code. I also agree that it's better not to give the user the option to omit too many arguments, but that's a design issue and sometimes unavoidable. Thanks for the feedback, Eyal. On Monday, October 6, 2014 4:20:18 PM UTC+3, Tom Boutell wrote: > > 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/26e3ff04-0931-4636-b3f5-4d8e4ec03d4a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
