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

[Jean-Baptiste Bugeaud]

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