PROPOSAL: Named method parameters

Paul Martin paul.martin at
Sat Mar 21 10:03:37 PDT 2009



> One small note: I see requirements to programmer:
> - pass parameters at same order

I tried to state that in the specification section, though I probably was
not clear enough (Neal Gafter also had a similar comment about
overloading).  I thought that nothing should change about the method call
(ordering, overloading) except that the parameter names would also be
checked to ensure that they matched.  Maybe it is similar to the type
erasure of generics - they are significant when compiling, but not so much
at runtime.

> - write @PublicParameterNames in all places, where can be parameter names:
> too restrictive.

I think that this may have been a contentious issue in the past - it seems
that paranamer was created because its authors didn't want to use such
annotations (which seems to have been discussed for Java 6) - see
However (for the reasons that I said in reply to Neal earlier in this
thread), I do like the idea of using annotations as documentation, to prompt
IDE suggestions, and to distinguish between code compiled for Java 7 (which
would support named parameters) and code compiled for earlier versions which
would not.

> 1. Are really ordering parameters by names in call is difficult task ? In
> worse case it is one extra loop.
> 2. For choosing policy to apply: parameter names by default if this is
> possible, looks for me, much cleaner.

In theory this could be done, though the overloading and overriding rules
would then become more difficult.  What happens if you have two overloaded
methods which have the same parameter names and types, but in different
orders, for example:

void method(int a, String b) and void method(String b, int a)

Currently these are treated as separate methods and can be resolved
correctly, but if named parameters allowed you to reorder them, then it
might be more difficult to choose the correct implementation (particularly
if there are other parameters that are not reordered, and/or you have a
hierarchy of overridden and overloaded classes).  This would also require
more extensive language changes (which I think would be out of scope for
project Coin).  I found the following blog entry from Alexander Buckley
which I think nicely explains this in more detail:

Also, thanks for mentioning paranamer - I meant to include that in the intro
of my email but forgot!

More information about the coin-dev mailing list