Axel, Your solution pretty much brings named arguments into Javascript. Pretty cool. First time I'm seeing this approach.
I think that in most other languages which don't have named arguments, users are not allowed to carelessly omit arguments. And if they do, they will encounter a compilation / runtime error before the function even starts to run. In JS we have the additional burden of validating functions' input. It's a sort of an additional defensive programming we have to do. Some say, btw, that as long as the docs state how to use the function, it's the user's responsibility to use it correctly. In JS users are used to calling functions by simply passing the arguments they want. And knowing that the function will just throw an exception if they misused it (a.k.a. "programmer error"). In this context, it might be worth reading this article <https://www.joyent.com/developers/node/design/errors>. As I mentioned before, any approach which does not follow the regular function-calling paradigm, will have to re-educate the users how to use the functions; which is not easy. For APIs for which it's known who are the users, it's definitely possible (internal / private libraries). But for public libraries I think we don't always have the luxury of changing our users' habits. About your solution - I think it's a nice approach. You said you are concerned with creating new objects at runtime due to performance. But any non-trivial solution will incur a performance hit. It should be interesting to do some benchmarks. Eyal. On Tuesday, October 7, 2014 3:21:25 AM UTC+8, Axel Kittenberger wrote: > > I agree about the motivation. > > Its not even only ambigious and optional argument lists, its even longer > argument lists that make a problem, since its often not clear to the callee > which argument means what. I never get it, why the order of arguments its > considered to be the only argument structuring mechanism to function calls > so many languages offer. > > Or argument lists that are changing in development or library releases. > That can be a pain to get them all correct again. > > I know, most people will say, just create an object literal and give that > to the function. Albeit this okayish for the occasional function, and more > and more standard API functions are adapting to this style or arguments I > don't like the idea of creating an object just for a single function call. > I know garbage collectors have become awesome, but it still seems > unnecessary waste to me, especially if that function is that 10% of code > that called often enough to be 90% of runtime already anyway. > > What I'm doing now is creating functions that take arguments with > alternating string specifier and parameter value. > > like: makeCoffee( 'sugars', 7, 'flavor', 'bitter', 'size', 4 ); > > I call it "free strings" method. > > In code I write it like this: > > makeCoffee( > 'sugars', 7, > 'flavor', 'bitter', > 'size', 4 > ); > > At first I would simple code makeCoffee like this: > > function makeCoffee( /* free strings */ ) > { > var > sugars = 3, // defaultValue > flavor = 'sweet', > size = 2; > > for( var a = 0, aZ = arguments.length; a < aZ; a+=2 ) > { > switch( arguments[ a ] ) > { > case 'sugars' : > // bla > break; > ..etc.. > } > } > > // actual function block > }; > > As its true it gets repetitive with not much expressiveness (albeit I > believe quite good in runtime), I then tried to code some generic > meta-handlers, like you did, but never was satisfied with the result. Again > it often resulted in creation of several ultra-short-lived objects on the > fly for each function call. > > Right now I'm using a code generator to create these repetitive code > blocks like aboth. However, its developing while I'm using it and yet not > in a state near to be released except eating my own dog food. > > To sum it up: I get the problem. I agree it is one. Actually ii is an > issue with javascript which it actually shares with most other dynamic > languages. Albeit not all! R for example has named arguments. There this > whole thing is nicely handled by the language itself -- as far I got it, > never coded much beside some "hello world"s in it. I believe a good > solution -- next to get ECMA to realize this and alter javascript itself to > get named arguments inkl. default values -- would be a meta language to > javascript (similar in working than coffeescript) that handles named > arguments to compile on the fly to javascript. Like with every metalanguage > there comes the issue with debugging, albeit this can be handled nowadays > with source maps. > > Or just accept and create lots of short lived object literals. Or improve > the Javascript runtime so much that a case can be done, that creating ultra > short lived object literals and parsing code for it is just as fast as a > classical ordered argument list. > > -- 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/be431b55-d664-469f-af92-b36e1441d7d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
