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/CABg07ftmorn1BEE8dOYsNOvEiYL0VWkDMBSMHPeGbVYFxVX%2BGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
