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

[Neal Gafter]

I'd suggest either jsr292 or a separate change fed into the underlying java
7 platform jsr (through the openjdk)

On Wed, Apr 22, 2009 at 5:41 PM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

> 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!
> http://tipit.to
>
>
> 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 zwitserloot.com> 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 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
>>
>>
>>
>
>