PROPOSAL: Named and Optional parameters, "Java-style"

Frédéric Martini frederic.martini at
Mon Aug 22 04:02:07 PDT 2011

I do not think it's a design problem.

It's a design problem because the Java language do no provide any
clean solution for that.

* Overload's method with different parameters count is very painful to
write, and confusing to use.
* The "Builder pattern" is also painful to write and to use, and the
documentation is separed from the method.

Some example with this proposal :

The 6 ResourceBundle.getBundle() can be replaced by a single method :

    public static ResourceBundle getBundle(String baseName, {Locale
loader=getLoader(), Control control=Control.INSTANCE);

The ProcessBuilder's class can be replaced by a single method :

	public static Process exec(String[] command, {
			File directory = new File(""),
			Map<String,String> env = null,
			boolean inheritEnv = true,
			Redirect stdin = Redirect.PIPE,
			Redirect stdout = Redirect.PIPE,
			Redirect stderr = Redirect.PIPE,
			boolean redirectError = false

Note : of course method/class will not be replaced for compatibility.
It's just an example of possibility for new API...

Another example : the Java 7 API java.nio.file use interface
OpenOption as varargs to allow us to use specific "flag".

	try { OutputStream out = Files.newOutputStream(path,
			StandardOpenOption.APPEND)) {

Using "named & optional args" may be more readable, with best EDI
support, and the possibility to use parameters values (and not only a
flag) :

	try { OutputStream out = Files.newOutputStream(path, sync:true, append:true)) {

If the "Collection Literals" is integrated into Java 8, it will be
possible to use it to simulate named & optional args using a
Map<String,Object> :

	// method :
	public static void method(Map<String,Object> map) {
		int foo = map.containsKey("foo") ? (Integer)map.get("foo") : 10;
		String bar = map.containsKey("bar") ? (String)map.get("bar") : "Hi";

	// actually :
	Map<String,Object> args = new HashMap<String, Object>();
	args.put("foo", 30);
	args.put("bar", "Hello World !");

	// With "Collection Literals" in Java 8
	method({"foo":30, "bar":"Hello World!");

But :
 - We lost all compiler support (type-check, name-check)
 - There no possibility for EDI support (autocompletion, etc.)
 - We must manually retrieve each parameter's value.

Le 22 août 2011 12:19, 向雅 <fyaoxy at> a écrit :
> Why so many parameters?
> It's design problem.
> 2011/8/22 Frédéric Martini <frederic.martini at>:
>> On my proposal, parameter's names are stored on a annotation.
>> But a class-file update would be better, even if it's "against the
>> spirit of coin".
>> 2011/8/18 Brian Goetz <brian.goetz at>:
>>> But, even if it did, another thing that makes a proposal "big" is "touching
>>> method overload resolution rules".  And the essence of this proposal is
>>> adding another layer of complexity to method overload resolution.
>> I think it does not affects method overload rules.
>> Like Java 5.0 varargs, this proposal is based on a special type that
>> will contains the parameters list.
>> For exemple, a methode like this :
>>     public void exemple({int foo=30, String bar="hi"})
>> will generate a method signature like this :
>>     public void exemple(OptArgs)
>> Adding optional parameters will not affect the method signature.

More information about the coin-dev mailing list