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

[Frédéric Martini]

(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")...


(B) That's true... and I fear that this implies a change in the bytecode :(


Le 20 octobre 2011 04:50, Reinier Zwitserloot <reinier at zwitserloot.com> a
écrit :

> This is one of those features that's near the top of my 'want' list, but,
> this proposal is not complete. The issues that I see with it:
>
> (A) How does this affect resolution of methods? If I have public void foo()
> and public void foo({int named = 5}), and somewhere also I call foo(), which
> method is called? Or, alternatively, how is the compiler going to prevent
> both of these methods existing? Will class files that somehow contain both
> anyway fail in the verifier, or is there an obscure resolution algorithm in
> these rare cases?
>
> (B) Your plan of sticking the relevant type information in an annotation
> doesn't work, because the classes you can stick in an annotation value
> cannot be generified, so, you can make int.class, but you can't make
> List<Integer>.class, just List.class.
>
>  --Reinier Zwitserloot
>
>
>