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

[Frédéric Martini]

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
targetLocale=Locale.getDefault(),
                                           ClassLoader
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.SYNC,
			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 !");
	method(args);


	// 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 gmail.com> a écrit :
> Why so many parameters?
> It's design problem.
>
>
> 2011/8/22 Frédéric Martini <frederic.martini at gmail.com>:
>> 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 oracle.com>:
>>>
>>> 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.
>>
>>
>