alternatives or complements to layers

Vitaly Davidovich vitalyd at gmail.com
Wed Jan 7 14:54:32 UTC 2015


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?

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


More information about the valhalla-dev mailing list