PROPOSAL: Named and Optional parameters, "Java-style"
frederic.martini at gmail.com
Thu Oct 20 05:33:18 PDT 2011
(A) I just say that this will not break existing code...
Of course the simple fact of changing an existing class can break
(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
> > and foo(Object...args).
> > In this case the empty foo() is called. We can opt for the same choice
> > But you're right : there is still a problem if we use varargs and
> > : foo(Object...args) and foo(Object named=null). Which method is called
> > I call foo() ?
> > I think it's reasonable to generate an "ambiguous" compilation error in
> > case, like when we have foo(CharSequence) and foo(Serializable) and we
> > 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
More information about the coin-dev