Sunday, September 28, 2003
Should Java support named and optional arguments?
Java 1.5 will extend the language with a number of nice features such as generics, autoboxing, enums, etc. Unfortunately, named and optional arguments aren't on the list. That's too bad. I believe that they would make the language easier to use and would not substantially increase compiler or runtime complexity.
Named (or keyword) arguments are supported in quite a few programming languages. They address shortcomings of so-called positional arguments. It's easiest to show the distinction with an example. First positional arguments in Java:
Named arguments are especially useful when combined with optional arguments (e.g. arguments with default values). C++ has support for optional arguments but not named arguments making them less useful. When a language only support optional arguments, and you want to specify the value of the second optional argument of a method that takes two optional arguments, you have to specify values for both optional arguments. When you combine named and optional arguments, you would only need to specify the second one.
Named and optional arguments are syntactic sugar. That's one reason I think they would be easy to add to the language. Maybe I should petition Sun to get them into Java 1.6
In the meantime, we can simulate these features. Optional arguments can be simulated by overloading a method with two different signatures. For example:
Named arguments can be simulated somewhat but they're a little trickier. The simplest technique is to create a value object to hold the arguments rather than pass them explicitly. Not as slick but the net effect can be similar. Another approach would be to use a HashMap as a general argument container. The downsides to this approach are that you lose type safety and you'd need to document the keys and types of the expected values. Pretty messy.
So what do you think? Should Java support named and optional method arguments?
Named (or keyword) arguments are supported in quite a few programming languages. They address shortcomings of so-called positional arguments. It's easiest to show the distinction with an example. First positional arguments in Java:
widget.handleIt( 1, 2, true, false );Next, named arguments in a hypothetical extension to Java:
widget.handleIt( x: 1, y: 2, show: true, enable: false );Because the arguments are no longer positional, this invocation would be legal as well:
widget.handleIt( show: true, enable: false, x: 1, y: 2, );Lots of programming languages support named arguments (e.g. Python, Ruby, Lisp). Even C# supports named arguments. But not Java.
Named arguments are especially useful when combined with optional arguments (e.g. arguments with default values). C++ has support for optional arguments but not named arguments making them less useful. When a language only support optional arguments, and you want to specify the value of the second optional argument of a method that takes two optional arguments, you have to specify values for both optional arguments. When you combine named and optional arguments, you would only need to specify the second one.
Named and optional arguments are syntactic sugar. That's one reason I think they would be easy to add to the language. Maybe I should petition Sun to get them into Java 1.6
In the meantime, we can simulate these features. Optional arguments can be simulated by overloading a method with two different signatures. For example:public void aMethod(int value) {This works okay but when you have a lot of arguments the number of methods can grow to a ridiculous number. And each calls the other in turn, filling the callstack with noise.
aMethod(value, true);
}
public void aMethod(int value, boolean flag) {
// do something useful
}
Named arguments can be simulated somewhat but they're a little trickier. The simplest technique is to create a value object to hold the arguments rather than pass them explicitly. Not as slick but the net effect can be similar. Another approach would be to use a HashMap as a general argument container. The downsides to this approach are that you lose type safety and you'd need to document the keys and types of the expected values. Pretty messy.
So what do you think? Should Java support named and optional method arguments?
RSS 0.92 Feed