PROPOSAL: Named method parameters (original) (raw)

Paul Martin paul.martin at gmail.com
Sat Mar 21 10:03:37 PDT 2009

Hi,

Thanks.

One small note: I see requirements to programmer: - pass parameters at same order

I tried to state that in the specification section, though I probably was not clear enough (Neal Gafter also had a similar comment about overloading). I thought that nothing should change about the method call (ordering, overloading) except that the parameter names would also be checked to ensure that they matched. Maybe it is similar to the type erasure of generics - they are significant when compiling, but not so much at runtime.

- write @PublicParameterNames in all places, where can be parameter names: too restrictive.

I think that this may have been a contentious issue in the past - it seems that paranamer was created because its authors didn't want to use such annotations (which seems to have been discussed for Java 6) - see http://paulhammant.com/blog/announcing_paranamer.html However (for the reasons that I said in reply to Neal earlier in this thread), I do like the idea of using annotations as documentation, to prompt IDE suggestions, and to distinguish between code compiled for Java 7 (which would support named parameters) and code compiled for earlier versions which would not.

1. Are really ordering parameters by names in call is difficult task ? In worse case it is one extra loop. 2. For choosing policy to apply: parameter names by default if this is possible, looks for me, much cleaner.

In theory this could be done, though the overloading and overriding rules would then become more difficult. What happens if you have two overloaded methods which have the same parameter names and types, but in different orders, for example:

void method(int a, String b) and void method(String b, int a)

Currently these are treated as separate methods and can be resolved correctly, but if named parameters allowed you to reorder them, then it might be more difficult to choose the correct implementation (particularly if there are other parameters that are not reordered, and/or you have a hierarchy of overridden and overloaded classes). This would also require more extensive language changes (which I think would be out of scope for project Coin). I found the following blog entry from Alexander Buckley which I think nicely explains this in more detail: http://blogs.sun.com/abuckley/entry/named_parameters

Also, thanks for mentioning paranamer - I meant to include that in the intro of my email but forgot!

More information about the coin-dev mailing list