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