alternatives or complements to layers

[Vitaly Davidovich]

And for cases where you don't want to materialize a string because the
underlying API supports outputting the type char-by-char, I'd probably
continue special casing that via type checks (i.e. manual overload
resolution).  It's not ideal, but (a) fairly rare, (b) confined only to
those classes that provide specialized versions, (c) only relevant for
printing things, and (d) keeps the specializer relatively simple, I think.
I'd hate for the specializer to be more complicated purely for this
scenario.

On Wed, Jan 7, 2015 at 10:01 AM, Vitaly Davidovich <vitalyd at gmail.com>
wrote:

> Personally I'd handle primitives as if they were value types from day 1:
> they get Object's hashCode, equals, and toString by allowing T.toString and
> rewriting it to their corresponding XXX.toString.
>
> Sent from my phone
> On Jan 7, 2015 9:57 AM, "Peter Levart" <peter.levart at gmail.com> wrote:
>
>> On 01/07/2015 03:54 PM, Vitaly Davidovich wrote:
>>
>>> But why make the specializer more complex and somewhat "magical" with
>>> fallback rules, widening/conversion operations,  etc? Why not add a <any
>>> T>
>>> println (T) version?
>>>
>>
>> You could, yes. But how would you implement it?
>>
>> Peter
>>
>>
>>> Sent from my phone
>>> On Jan 7, 2015 9:39 AM, "Peter Levart" <peter.levart at gmail.com> wrote:
>>>
>>>  On 01/07/2015 03:08 PM, Vitaly Davidovich wrote:
>>>>
>>>>  If you're authoring a generic class and call one of these overloaded
>>>>> methods, which one is called? What's the return value (for non void
>>>>> ones)?
>>>>>
>>>>>  What's the return value of a lambda expression with multiple returns?
>>>> What's the return value of "condition ? expression1 : expression2" ?
>>>>
>>>>   The final target method is only known when a user instantiates your
>>>> class
>>>>
>>>>> and provides the type, but not at authorship.
>>>>>
>>>>>  At authorship you know which method will be chosen for each possible
>>>> instantiation. There are only a limited number of methods. There has to
>>>> be
>>>> a "last-resort" method taking Object parameter(s) or such invocation
>>>> does
>>>> not compile.
>>>>
>>>> Take for example the overloaded methods of System.out.println(). Which
>>>> method is choosen in this example:
>>>>
>>>> <T> void test(T x) {
>>>>      System.out.println(x);
>>>> }
>>>>
>>>> ...it's always the println(Object) right?
>>>>
>>>> With primitive (and value type) instantiations, there are not so many
>>>> other options. Primitives have more options since they can do implicit
>>>> widening conversions AND boxing, but other value types will either
>>>> choose
>>>> the method taking exact value type if available, the next preference
>>>> would
>>>> be the boxed equivalent and finally the fallback to Object.
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>>  Sent from my phone
>>>>> On Jan 7, 2015 9:04 AM, "Simon Ochsenreither" <simon at ochsenreither.de>
>>>>> wrote:
>>>>>
>>>>>   The other option is to fail compilation if any-T context is calling
>>>>> a non
>>>>>
>>>>>> any-fied method and require user to do a cast on their T to select the
>>>>>>> proper overload (including possibly casting to Object).  I don't
>>>>>>> know if
>>>>>>>
>>>>>>>  we
>>>>>>
>>>>>>  want the method "late bound" like that.  Also, suppose the different
>>>>>>> overloads return different types - the writer of code has to know
>>>>>>> what
>>>>>>>
>>>>>>>  the
>>>>>>
>>>>>>  type will be upfront.
>>>>>>>
>>>>>>>  I think the interesting question is "is there a reason why an
>>>>>> any-fied
>>>>>> parameter couldn't act as a compatible replacement for methods with
>>>>>> Object + primitive overloads?". Because that's what any does under the
>>>>>> hood already: Create additional methods for non-reference types.
>>>>>>
>>>>>>
>>>>>>
>>