PROPOSAL: Named method parameters

[Paul Martin]

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