alternatives or complements to layers

[Peter Levart]

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