alternatives or complements to layers

[Vitaly Davidovich]

The other option is to fail compilation if any-T context is calling a non
any-fied method and require user to do a cast on their T to select the
proper overload (including possibly casting to Object).  I don't know if we
want the method "late bound" like that.  Also, suppose the different
overloads return different types - the writer of code has to know what the
type will be upfront.

Sent from my phone
On Jan 7, 2015 8:44 AM, "Peter Levart" <peter.levart at gmail.com> wrote:

> Hi,
>
> While experimenting a bit with the current preliminary prototype, I found
> myself on several occasions wanting to call a method from "normal" API. Say
> System.out.println(x) with an x of type "any T". Usually a method that
> already has various overloads or a method taking an Object. Javac refuses:
>
>     method PrintStream.println(boolean) is not applicable
>       (argument mismatch; T cannot be converted to boolean)
>     method PrintStream.println(char) is not applicable
>       (argument mismatch; T cannot be converted to char)
>     method PrintStream.println(int) is not applicable
>       (argument mismatch; T cannot be converted to int)
>     method PrintStream.println(long) is not applicable
>       (argument mismatch; T cannot be converted to long)
>     method PrintStream.println(float) is not applicable
>       (argument mismatch; T cannot be converted to float)
>     method PrintStream.println(double) is not applicable
>       (argument mismatch; T cannot be converted to double)
>     method PrintStream.println(char[]) is not applicable
>       (argument mismatch; T cannot be converted to char[])
>     method PrintStream.println(String) is not applicable
>       (argument mismatch; T cannot be converted to String)
>     method PrintStream.println(Object) is not applicable
>       (argument mismatch; T cannot be converted to Object)
>   where T is a type-variable:
>     T extends <any> declared in method <T>test()
>
>
> But we know that whatever instantiation of T we choose, at least one of
> available overloaded methods would apply. If the set of overloaded methods
> contains one with parameter of type Object, then any instantiation of
> parameter of type "any T" would apply to at least one of those methods. At
> specialization time, the most appropriate method could be "selected".
>
> Of course this would not automatically route reference typed parameter to
> the most appropriate method among those taking various reference types -
> the one taking Object would always be chosen, but any value typed paremeter
> could select the most appropriate method (with implicit conversions and/or
> boxing).
>
> This could be viewed as a more natural complement to "layers" for
> supporting implementation by parts.
>
> The specializer would either have to inspect the target class somehow, or
> javac could provide the set of applicable methods in an attribute
> associated with invocation. Or perhaps, such invocation could be
> "specialized" as invokedynamic where the linking to the most appropriate
> method (with implicit conversions and/or boxing) would be choosen at 1st
> invocation.
>
> What do you think?
>
>
> Regards, Peter
>
>