PROPOSAL: Named and Optional parameters, "Java-style"

[Frédéric Martini]

(A) I just say that this will not break existing code...
Of course the simple fact of changing an existing class can break
compatibility.


(B) It seems to me that parameter's name is not always present on the
bytecode, like when you compile with no debugging info (-g:none).

Using JSR292 and invokedynamic is a great approach for this problem !
But it should not be possible on all methods, to avoid possible
incompatibility on the future...



2011/10/20 Rémi Forax <forax at univ-mlv.fr>

> On 10/20/2011 11:14 AM, Frédéric Martini wrote:
> > (A) We already have this problem with varargs. For example with method
> foo()
> > and foo(Object...args).
> > In this case the empty foo() is called. We can opt for the same choice
> here.
> >
> > But you're right : there is still a problem if we use varargs and
> named-args
> > : foo(Object...args) and foo(Object named=null). Which method is called
> when
> > I call foo() ?
> >
> > I think it's reasonable to generate an "ambiguous" compilation error in
> this
> > case, like when we have foo(CharSequence) and foo(Serializable) and we
> call
> > foo("Hello")...
>
> In that case, adding a default value to an existing method is not source
> compatible !
>
> >
> >
> > (B) That's true... and I fear that this implies a change in the bytecode
> :(
>
>
> http://weblogs.java.net/blog/forax/archive/2011/01/21/jsr-292-goodness-named-parameters
>
> Rémi
>
>
>