PROPOSAL: Named method parameters (original) (raw)
Paul Martin paul.martin at gmail.com
Sat Mar 21 09:48:54 PDT 2009
- Previous message: PROPOSAL: Named method parameters
- Next message: PROPOSAL: Named method parameters
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
Annotations should not affect the semantics of any other language construct. I think if you want to add support for named parameters, the support should be available everywhere.
Yes, perhaps this is contentious. I suppose that I had a few areas that I wanted to address:
- Ease of implementation - using annotations seems like a relatively low-impact way of getting named parameters (both in adding and retrieving the parameter name metadata). It is perhaps less powerful than integrating them directly into the core of the language, but that wouldn't fit within the scope of Coin (and I'm not sure that I'd want to wait for Java 8 until I had a good solution for creating immutable objects).
- Documentation / IDE support - using annotations can also suggest where named parameters should used.
I thought that the annotations are somewhat like @Override, in that we are not changing much of the behaviour of the compiled classes (other than automatically including appropriate generated @PublicNamedParameter annotation), since the selection of the method to be called and the order of the parameters will not change, but instead the annotations are primarily concerned with validating the code.
The alternative would be to allow named parameters to be used to call all methods. This could still be implemented by automatically generating @PublicNamedParameter annotations, so wouldn't necessarily affect the proposal much (and @PublicNamedParameters annotations could also be used on methods, etc. for documentation / IDE suggestion purposes if really required). However I couldn't think of a good solution when working with legacy class files (compiled prior to Java 7), since they would not support named parameters but it would not be obvious to a developer why they didn't. The annotations would at least make that explicit.
Do you think that there (language) areas that would not be covered by the use of named parameters?
What are the changes to the spec for overload resolution?
I thought that named parameters should not affect overload resolution at all
- so you could not overload based upon parameter names, you would only be able to overload based upon parameter types. Named parameters can then really just be thought of as providing some level of code documentation and verification to the compiler, along with support for runtime frameworks (such as Spring) to similarly verify parameter names.
Do you think that named parameters in principle are a good/reasonable idea?
Thanks,
Paul
- Previous message: PROPOSAL: Named method parameters
- Next message: PROPOSAL: Named method parameters
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]