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