alternatives or complements to layers

[Vitaly Davidovich]

Yes, PrintStream.println() appears to materialize strings, so that's doable
"as-is".  A more interesting case is, e.g., AbstractStringBuilder.append(),
which has specialized primitive versions that do not materialize strings.

On Wed, Jan 7, 2015 at 10:37 AM, Peter Levart <peter.levart at gmail.com>
wrote:

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