Optional Parameters
Sebastian Sickelmann
sebastian.sickelmann at gmx.de
Sun Nov 20 20:40:50 PST 2011
Hi,
While reading the suggestions on method chaining from Eirik Lygre at
jdk8-dev yesterday the first mindset i got is another kind of "method
chaining". Its more or less the idea that is described from Frediric
Martini recently (01.09.2011) on this list but without the named
parameters part.
Maybe there are the same reasons why named parameters are not considered
as coin feature. But i think a simple pattern which enables
default-parameters and reduces "method-chaining" at compile-time ca be
coin-ish enough.
There are some places in jdk and many in other public libraries that use
code like this.
public class MyClass {
public static final BarB BAR_DEFAULT_B = ...;
public static final BarC BAR_DEFAULT_C = ...;
public Bar foo(BarA a) {
foo(a,MyClass.BAR_DEFAULT_B);
}
public Bar foo(BarA a,BarB b) {
foo(a,b,MyClass.BAR_DEFAULT_C);
}
public Bar foo(BarA a,BarB b,BarC c) {
...
}
}
The concrete types "Bar?" are really irrelevant. I think this code
snipplet can be reduced to something like this.
public class MyClass {
public static final BarB BAR_DEFAULT_B = ...;
public static final BarC BAR_DEFAULT_C = ...;
public Bar foo(BarA a,BarB b=BAR_DEFAULT_B,BarC c=BAR_DEFAULT_C) {
...
}
}
This can expand to be upper one, so this issue is just an stringtemplate
expansion for the compiler. There is an javadoc issue too, but i think
the most important part (the semantics of the default values) can be
handled in the javadoc comment of the method that defines the default
parameter values.
I see mainly two implementation scenarios. The first result is described
above. The second is replacing the complete list of parameters in every
generated method. So the first method looks something like this:
public Bar foo(BarA a) {
foo(a,MyClass.BAR_DEFAULT_B,MyClass.BAR_DEFAULT_C);
}
I think the second implementation scenario is slightly better, because
it reduces stack-traces sizes or is there a way to disable
"stacktrace-insertion".
The main downside i see is the "stacktrace-insertion". This can really
confuse some programmers.
And then there is the usual downside of reducing the syntactic-room for
further changes to syntax and adding more complexity for implementators
of IDEs.
-- Sebastian
More information about the coin-dev
mailing list