I have seen no one propose this, but I’ve been thinking for a while that it would be really helpful in situations where you have lots of optional parameters. It would be great for constructor injection, argument passing on a program interface, embedded DSLs/fluent interfaces, etc.
I really like the idea of named arguments, although I'm not sure if they are the best solution for all the things mentioned above: DSLs in Java? Without operator overloading?.
Anyway, it believe they would make Java Code (even more) readable and the usage could prevent mistakes:
Documentation and parameter re-ordering are nice, but it would be really cool to have default values along with them:
However, when does it end? Imagine indexed varargs:
And did I hear critics say "But named methods can simulated with a dedicated bean (having a corresponding property for each method parameter)!"
Well, that would leads to lots of grabage of code (and objects inside the jvm):
Summing up, I think this would be a minor but not less worth language change to consider for Java 7 (or 8). Especially since everything above should be 100% backward compatible and YOU DON'T HAVE TO USE EM!
What do you think: Take it or leave it?
12 comments:
They should have been part of Java 1.0.
Named arguments can make code much better readable. So you have my vote.
Awesome! Great writeup of what I was too lazy to flesh out... :)
One thing to consider is be the evaluation order:
boolean neg(boolean b) { return !b; }
void foo(boolean first, boolean second)
{
out.println(first + " " + second);
}
boolean b = true;
foo( second : (b = neg(b)), first : (b = neg(b)) );
It will be either defined by the method definition or the method call.
I'm in favor for the latter option, because I'm to lazy to it up :-)
see http:/paranamer.codehaus.org for access to parameter names for the current editions of java. PicoContainer 2.0 uses it for dependency injection, and http:/waffle.codehaus.org uses it for action method binding.
Paul Hammant
I'm trying to like this idea, but I think I'd prefer something like the Ruby-style hash notation with symbols as keys. You get the same sort of readability benefits but with more flexibility.
Unfortunately hashes are not part of the language -- HashMap is just a class in the library -- so it may not be a realistic wish.
Named arguments + default values would make the code a lot more readable. I hate method overloading just to add a few optional arguments
of course, this needs to coincide with native property support so that the appropriate setter is called if it exists. :)
"Hallo".replace(newCahr = 'e', oldChar = 'a'); // this too: but unexpected
Presumably this would cause a compile warning (unless newCahr was actually misspelled in the method signature...)
it does work with a standard java compiler without any warnings, if you have declared the variables before:
char newCahr, oldChar;
thees have nothing to do with the names used declaring the method or the proposed named arguments..
I used this feature in another language. It allowed parameters to be specified as optional, and to specify default values. When calling the method you could switch from unnamed to named mode once part way through the list. eg:
mymethod("infile","outfile",oddOption=true);
In this way methods opften end up with lots of infrequently used parameters on the end of the parameter list marked as optional.
Definitely it makes code more readable. Another use is to add optional parameters without having to recompile the calling code.
Murray Hughes
You can do it to some extent with annotations although it will be a pain..
replace(@OldChar a, @NewChar e);
I absolutely share your opinion. Java lacks a highly useful feature.
Post a Comment