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

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

This proposal can also be based on the "Collection Literals",
coin-dev at :

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