alternatives or complements to layers

Peter Levart peter.levart at gmail.com
Wed Jan 7 14:22:20 UTC 2015


On 01/07/2015 02:54 PM, Vitaly Davidovich wrote:
> The other option is to fail compilation if any-T context is calling a non
> any-fied method

This is how it works now.

>   and require user to do a cast on their T to select the
> proper overload (including possibly casting to Object).

This would not buy anything. I would like specializations to choose 
different overloads.

>    I don't know if we
> want the method "late bound" like that.

If we take "specializations" as something that is automatically 
generated on demand what would otherwise have to be written by hand, 
then the binding "happens" at compile-time - javac verifies that any 
specialization can choose the most appropriate overload. It's just that 
each specialization can choose a different overload.

> Also, suppose the different
> overloads return different types - the writer of code has to know what the
> type will be upfront.

Well, that's right, but also lambdas have multiple "returns" and we have 
target typing. Frequently, overloaded methods have all same return type 
(including void).

It would be nice to have such a feature. It feels natural.

Regards, Peter

>
> 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
>>
>>



More information about the valhalla-dev mailing list