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

Reinier Zwitserloot reinier at
Wed Apr 22 17:41:31 PDT 2009

Neal: No, this is not an API change. It's a change to the JVM spec  
(specifically, the section about class files). If it doesn't fit  
project coin, then what would it fit? Most certainly not the coin-but- 
for-API-updates. Where else would 'class files MUST include the names  
of method parameters' fit?

Adding the ability to get this information via reflection would be an  
API change, but many coin proposals have a matching change to the  
reflection API.

  --Reinier Zwitserloot
Like it? Tip it!

On Apr 20, 2009, at 17:52, Neal Gafter wrote:

> Reiner-
> This is a library proposal, not a language proposal, so it doesn't  
> need to be done inside project Coin.
> -Neal
> On Mon, Apr 20, 2009 at 3:16 AM, Reinier Zwitserloot <reinier at 
> > wrote:
> 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>:
> >> 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  
> > 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  
> > 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

More information about the coin-dev mailing list