SUBMISSION : A second look on "named parameters" / Clarification on the scope

[Reinier Zwitserloot]

Ah, now I understand.

I've got a much simpler proposal to address this issue.

NB: Joe, I know coin's long gone, but perhaps consider this one anyway  
- it seems to me that some sort of named parameters proposal is likely  
to be accepted in the future, and adding names now should ease  
transition. As part of the effort I've listed all possibly  
complication I can come up with, at the end.

Proposal:


Starting from the new class file format introduced in java7 (due to  
module support, the class format is definitely getting a version  
bump), all compilers MUST put the names of the parameters in the class  
file (javac -g style), and obfuscators/compressors/whatever MUST NOT  
remove this; a class file with version v50 (or whatever number its  
going to end up being) won't even pass the verifier without the names  
in place.

Add an API call on the java.lang.reflect.Method object to obtain the  
names of the parameters (returns a String[], or 'null' if they aren't  
there. Calling this on a param-less method returns an empty array, not  
null). Having the names is an all-or-nothing situation: Either the  
names are all there and this call works, or some/all are missing, and  
then this call does not work. I'm not sure if you can even have just a  
few names defined in the .class file format, but even if you can, that  
situation should be so extremely rare, its not worth writing up a  
complicated rule for). It is guaranteed that if the array exists (is  
not null), then each array element is not null.

Voila. No need to turn in a proposal that's more complicated than most  
just to solve this simple problem.

Complications:

A) It would no longer be possible to rewrite a v49 and below class  
without debug info into a v50 and up class file without having the  
source file, but I don't actually know of any tools that attempt to do  
this.

B) Code that generates class files on the fly (like proxy generators  
and the like) will need to consider the names of method parameters if/ 
when they update the class file format they generate to v50+. A proxy  
generator has issues when it is trying to generate a v50+ proxy where  
its input object's class spec AND the input interface to proxy on are  
both v49- without debug info, for example.

C) A (bad) quick-fix for either of the above issues is to just use  
'arg0', 'arg1', 'arg2', analogous to what e.g. eclipse does when  
showing method signatures for methods in classes where there is no  
source, no debug info and no javadoc. This is not at all the right  
idea. A small risk that the class file format documentation should  
mention as not being appropriate unless there is absolutely no other  
option.

D) Most code these days ships with source, or javadoc, or debug info,  
so that auto-complete shows the proper names for each parameter, but  
this certainly isn't true for /all/ java code out there. After this  
change, method param names become visible to all. This may not be a  
desired side-effect for programming shops that export libraries to  
clients where their method parameter names are inappropriate (swear  
words, or 'x', 'y', and 'z' and this creates deserved but nevertheless  
unexpected ridicule for sucking at programming style). I think this is  
an acceptable price to pay. Parameters are method-local which are  
extremely easy to rename with your friendly neighbourhood IDE's  
refactor tool.

E) While technically the names are NOT part of API, and you CAN freely  
change names around without breaking any code, old or new, the names  
still do become a little more enshrined as at least almost part of the  
public API. This is already the case to some extent (param names show  
up in various tooling support such as javadoc and auto-completing  
IDEs) but this change would move parameter names a little more towards  
a complete member of public API. This is an issue, but its also the  
point of this proposal: Move towards a java world where parameter  
names are universally available and are meaningful. I don't think this  
is a serious problem, because A) names already have a flavour of  
importance right now, and B) While they become more important with  
this proposal, they still aren't true public API, and changing names  
even after this proposal is accepted is not backwards incompatible.

F) Confusion may arise when these names are unintentionally taken as  
being either part of public API, or being hierarchical; they are in  
fact neither. For example, this proposal makes no attempt to harmonize  
name conflicts; if interface A has void foo(int bar), and interface B  
has void foo(int baz), you can still of course write a class that  
implements both of these. You can even name your foo's parameter  
'floobargle', of course. The aim of this proposal does not involve  
making parameter names inherit sensibly.


  --Reinier Zwitserloot



On Apr 20, 2009, at 10:18, Jean-Baptiste Bugeaud wrote:

> Hello Reinier, Hello Joe,
>
> Thanks for your feedback.
>
> 2009/4/19 Reinier Zwitserloot <reinier at zwitserloot.com>:
>> Your proposal is very incomplete. Three major nits:
>>
>> A. Did I miss something, or did you totally forget to include an  
>> example of
>> calling a method with named parameters? Something like:
>>
>> doLogin(user: "foobar", password: new char[] { 'a', 'b', 'c' })
>
> Reiner, I think my submission name is misleading everybody. This is
> not the same thing you debate some times back. My mistake ... I should
> have clarified from the start : I do not look at adding direct call by
> parameter name into the language (say "à la" ObjectiveC). But simply a
> reliable way access to parameter name and name a parameter's name in
> static way thru time. See bug 6444738 for differences.
>
> Parameter names are very usefull information in most cases, and at
> this time, either implementers use duplicate annotation (dummy
> annotations storing again the same name) or they use tools such as ASM
> to workaround the lack of API in the JDK.
>
> At the begining, I thought this requirement did not required a small
> synthax language change : a new API would be enough. But soon I
> realized that introducing name parameter that are static thru time,
> introduce anyway a new paradigm in the language that developer should
> be able to control directly : do I want this parameter name to be
> static thu time ? or do I want to let the compiler decide as usual ?
>
> A compiler option is not the suitable tool for this.
> If this is a global switch, it will not offer the fine grain required.
> If this is a per class/per package option, it will clutter the  
> command line.
> And in both cases, it will not offer paradigm separation with the
> legacy. Thus you can not rely on the parameter name because you never
> know if developper has stored the name accidentaly or for purpose.
>
>> B. Why static? You might as well have picked 'strictfp' - it's a  
>> total
>> non-sequitur choice. Re-use of existing keywords is not really a  
>> panacea; it
>> waters down the anchoring ability of a keyword to virtually  
>> nothing. I'm not
>> sure if context-sensitive keywords are any better, but java7 is  
>> already
>> going to have at least one ('module'), so don't beat around the  
>> bush and
>> just call it 'named'). Could be just me, but introducing a change  
>> which is
>> not backwards compatible IF you have a type that's called  
>> 'named' (written
>> just like that, all-lower case), is not something I find  
>> troublesome in the
>> least. That's very ugly code, and a migration tool can fix this  
>> easily.
>
> Because of the definition a dictionary gives of it : something like
> "showing little change" is exactly what I meant for this paradigm. And
> no "strictfp", as well as "const" and "goto" are not matching, you see
> ;-)
>
> If you think that this worth integrating a new keywork, then there is
> room for debate. I think static fits perfectly and is clear enough.
> AFAIK, we already have final that is contextual? why not static too ?
> final is already stretched between two things : do not overload member
> and do not reasign variable.
>
> With the proposed language changed static modifier will be stretched
> between static thru instances for members and static thru time for
> variables.
>
>> C. You don't mention having default values for parameters, which is  
>> sort of
>> the point of this exercise (otherwise you really still need  
>> builders  ; any
>> method that has so many parameters that they need names probably  
>> needs a
>> builder, and without defaults, not providing one and instead  
>> relying on
>> named params is just an inferior bandaid to your ugly API; to get  
>> it right
>> you STILL need to provide a builder. If, however, parameters can have
>> defaults, then you no longer need to make builders at all).
>
> This is because I am not asking for named call of method ... simply
> for a way to access name of parameter. Just a completely different
> topic.
> I don't see why a parameter on an EJB is not meanfull for the external
> ? same for an webservice ? why a parameter name could not be meanfull
> ? I don't get your point.
>
> My design decision is the kind of decision that led to erasure based
> genericity : it has some drawback, loss of real parametrics instances
> that could be usefull while reflection. But was the right decision at
> the right time or either we would have lots binary compatibility or we
> would still be debating wether or not implementing generics.
> 	
> My proposition on parameter name is analog, it is just meant to be
> used ASAP but does it does not fully solve all the possible
> expectations from this topic scope. Namely, should we call "by
> parameter name" in the language ? and how ?
>
> Room is let for the coming decade ;-) But the propopsition does not
> close doors to anything.
>
>> I suggest you look over the coin-dev mailing list; I entered a  
>> rough sketch
>> of a named parameters proposal near the end of coin. I never wrote  
>> it up
>> because I thought of it far too close to the deadline, and it's  
>> still of
>> such high impact that I doubt it would pass muster for coin.
>
> Yes I've followed the debate :) But, again its my mistake "call by
> parameter names" is a much more complex topic with lots of
> performance/plaform impact. This is not a small language change IMHO.
> Again, I do not look for calling a direct method call using named
> parameters .... just a way to retreive them.
>
> -- --
>
> Joe, yes "late I am" ;-)
>
> FYI, I got this proposition cooking for several months I was not able
> to find time to write & post it to you (pittyfull isn't it).
>
> If we remove the "language change" part (static named parameter) and
> only keep the getParameterNames() API part (keep the regular parameter
> name), do you think this can be pushed to JDK7 even if out of scope of
> coin ? This is a very small change to the API and would solve lot of
> time from lot of people.
>
> I mean, this API (along with the rest of the named parameter spec) was
> removed from JDK6, skiping this in JDK7 means years again to wait for
> it ? I think we are too much getting dependent on tools such as ASM in
> lots of places (JavaEE implementation stacks for instance). And we
> have a good opportunity to remove the dependency for a clean/simple
> solution IMHO.
>
> Best Regards,
> JB