alternatives or complements to layers

[Maurizio Cimadamore]

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
>