alternatives or complements to layers

[Peter Levart]

On 01/07/2015 04:01 PM, Vitaly Davidovich 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.

Ok, there are alternatives for Object methods, yes. So that available 
operations on "any T" are at least those. But you have to define them 
upfront and then they are baked in the language. Without those, you are 
confined to the world of "any T" methods from which you can't escape to 
interact with the "real world".

I view this hypothetical feature as an alternative or complement to 
"layers". But it can also be viewed as a kind of "extension 
(multi)methods" for value types.

Peter

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