PRE-PROPOSAL: Named method parameters with defaults.

Reinier Zwitserloot reinier at
Sun Mar 22 07:53:57 PDT 2009

As Vilya suggested, with default parameters, the need for overloading  
mostly goes away.

However, I don't see how the restriction can go away. Given:

public named void foo(String arg1, int arg2 = 5, String arg3 = "foo") {}

public named void foo(String arg1 = "bar", String arg3) {}

which method is to be called for this method invocation:

foo(arg1: "a", arg3: "b");

There's absolutely no way to tell.

There are plenty of tricks to apply to ensure the above situation  
cannot occur, but trying to write up a formal spec for those feels  
extremely un-coin-ish.

My proposal involves foregoing the ability to overload for now; there  
is nothing in the proposal that prevents a future addition to the JLS  
to allow it, including the complex ruleset needed to ensure ambiguous  
situations cannot occur.

An attempt at a ruleset to allow overloading:

1) For all named methods, first produce a signature list. This list  
consists of treating each parameter type/name pair as either existing  
or not existing (IF it has a default), or existing (if it does not).  
So, the first 'foo' method above would boil down to this list:

void(arg1: String, arg2: int, arg3: String)
void(arg1: String, arg2: int)
void(arg1: String, arg3: String)
void(arg1: String)

2) For each method name, concatenate all the lists.

3) Check if there are duplicates in the list. A duplicate consists of  
100% match between BOTH name AND type. If there is such a duplicate,  
generate a compile time error. If there is NO such duplicate, that  
doesn't neccessarily mean it will compile; the usual rules of  
overloading still apply. The following two methods would be okay under  
this ruleset but still wouldn't compile:

named void foo(String arg1, String arg2) {}

named void foo(String arg3, String arg4) {}

I'd love to write it up if somebody gives me some direction in regards  
to whether this is A) A good idea, B) fits within coin, and C) Should  
or should not include the extra complication listed above.

  --Reinier Zwitserloot

On Mar 22, 2009, at 01:30, Neal Gafter wrote:

> On Sat, Mar 21, 2009 at 3:21 PM, Reinier Zwitserloot <reinier at 
> > wrote:
> Of all methods that have the same name (but different paramlists, e.g.
> overloading), only one is allowed to be named in the first place.
> Honestly, I think this is a fatal restriction.  I like named  
> parameters, but not if restricted to a single member of any overload  
> set.

More information about the coin-dev mailing list