PRE-PROPOSAL: Named method parameters with defaults. (original) (raw)
Paul Martin paul.martin at gmail.com
Sun Mar 22 06:35:32 PDT 2009
- Previous message: PROPOSAL: Named method parameters
- Next message: PRE-PROPOSAL: Named method parameters with defaults.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: PROPOSAL: Named method parameters
- Next message: PRE-PROPOSAL: Named method parameters with defaults.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]