PRE-PROPOSAL: Named method parameters with defaults.

[Reinier Zwitserloot]

I just don't see much value in named parameters without having  
defaults (or using them to choose between overloads, but that would  
require massive changes). Defaults without named parameters does have  
interesting use cases, but withOUT named parameters, you add two extra  
complications that do NOT exist if you force-combine them with named  
parameters:

1) Given: foo("bar");, which of the two parameters is supposed to be  
"bar" and which is supposed to be "foo" if the method sig is:

public void foo(String a = "foo", String b = "bar") {}?

That problem does not arise with named params.

2) For backwards compatibility reasons, defaults don't kick in unless  
a compiler specifically accounts for them (after all, its magic that  
occurs mostly on the invocation side!).Your method is essentially  
flagged. The 'named' keyword makes this process less transparent,  
which is IMO a good thing.


In other words, only the defaults aspect of it is worth separating,  
but separating that doesn't really make the proposal much simpler.

If I'm undervaluing the benefits of named parameters, by all means,  
fill out a proposal yourself and/or edit the one I'll be writing up.  
Contact me so we can work together.

  --Reinier Zwitserloot



On Mar 22, 2009, at 14:35, Paul Martin wrote:

> 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
>