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

Frédéric Martini frederic.martini at gmail.com
Mon Aug 22 03:18:31 PDT 2011


This proposal can also be based on the "Collection Literals",
coin-dev at openjdk.java.net :
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001193.html



So, an "Named & Optional" bloc can be compiled as a Map<String,Object>.
(Of course it would be preferable to use a more specific type instead
of Map<String,Object>, in order to avoid possible conflicts)




So, this code :

	public void method({int foo, String bar="Hello"}) {

		...
	}



Would be compiled to something like this :


	public void method(Map<String,Object> $args$) {
		int foo    = UtilityClass.retrieve($args$, "foo", int.class);
		String bar = UtilityClass.retrieve($args$, "bar", String.class, "Hello");

		...
	}




Like Java 5.0 varargs, the compiler will generate a method with a
specific type, so there should be no impact on the method overload
resolution rules.




The only ambiguity is about overload.
The method call "method()" can match the following three methods :


	public void method();
	public void method(Object...);
	public void method({int optionalArgs=0});


Actually, between the first two, compiler will choose the first one.
We can use the same rules : compiler will opt standard method, varargs
method or "named&optional" method, in this order.



More information about the coin-dev mailing list