alternatives or complements to layers

[Peter Levart]

On 01/07/2015 04:22 PM, Maurizio Cimadamore 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.

Ok, I buy that, but it would mean that existing core libraries would 
have to get a massive update.

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

It was said that an option is for all value types (including primitives) 
to get 3 Object methods (hashCode, equals, toString). So at least 
println is doable.

Regards, Peter

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