PRE-PROPOSAL: Named method parameters with defaults.

[Paul Martin]

Hi,

In reply to Reinier Zwitserloot's pre-proposal:

Could you separate named parameters from default parameter values into
two proposals, since I don't think that they need to be directly
related?

Could you take the C++ approach of only allowing default values for
parameters at the end of the parameter list?  The compiler could then
synthesise additional overloaded methods with and without the default
parameters being used.  Rather than having a shared instance variable
(which would not work for static methods, would not be thread-safe,
and could only use immutable objects, unless I misunderstood your
explanation), could the compiler just add extra statements to the
beginning of each method to initialise the default value (depending
upon whether the parameter was passed)?

This does of course mean that default parameters can only be used at
the end of the parameter list, but is perhaps easier to integrate.
However, I'm not sure how @Override would be handled - what would
happen if you overrode a method and then added an extra default
parameter (calls made using a default value for the new parameter are
effectively calling a method that overrides the original, but calls
that specify a value for the new parameter are not).  Maybe that would
just be an error?

After that, I think that your suggestion for named parameters seem
largely similar to mine, though with different implementation details:
- 'named' keyword instead of @PublicParameterNames annotation
- Only one named method for overloaded methods and same parameter
names for overridden methods instead of not having those restrictions
(I am not sure why you thought that you needed them - was that the
interaction of default parameters?)
- Store parameter names using debug-style mechanisms instead of adding
annotations (I wasn't really aware that this could be done).

I'm not too concerned about the particular implementation approach
chosen, as long as the result is reasonable!  How far do proposals in
project coin have to go when specifying implementations?


More generally, does anyone know why named parameters were not
implemented in earlier versions of Java?

Paul