alternatives or complements to layers

[Vitaly Davidovich]

>
> We can just consider the set of overloaded println (Object + primitives)
> 'good enough' for an 'any X'; what if X is an instance of a value class?


Well, if you're going to go down the road of having the specializer pick
overloads, it should pick the most specific one, preferring non-generic
methods over generic ones.  If there's a non-generic target method that
takes the exact type, it's picked (irrespective if it's value or reference
type).  If there's a generic method that's applicable, it's picked.
Finally, pick Object, and box the value type/primitive.  I would not
consider widening conversions of primitives as candidates (i.e. T=int,
there's no int overload but there is a long one -- I would not consider the
long variant as eligible).

On Wed, Jan 7, 2015 at 10:22 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Peter,
> I found this often too (and it is frustrating!) when trying to apply some
> of the valhalla magic on our collection classes (the case I found was
> System.arraycopy, which suffers from similar issues). I believe the pain we
> are feeling now is both (a) benign and (b) transient. It is benign because,
> in one way, it makes you see how 'old' the API look once you fullt embrace
> the idea of a unified type-system; if we were writing this from scratch,
> println would probably something like:
>
> <any Z> void println(Z z);
>
> And then it would be implemented by parts using peeling.
>
> The 'transient' nature of this pain is because we are working with a
> unified language, but an erasure-based library; I believe that this method
> (and other similar ones) will have to be rewritten (or an extra 'any'
> variant added) so that they work uniformly with specialized generics.
>
> P.S.
> We can just consider the set of overloaded println (Object + primitives)
> 'good enough' for an 'any X'; what if X is an instance of a value class?
>
> Maurizio
>
>
> On 07/01/15 13:43, Peter Levart 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
>>
>>
>