alternatives or complements to layers

[Vitaly Davidovich]

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