alternatives or complements to layers

[Vitaly Davidovich]

Methods that you want to invoke that aren't part of Object should be
handled by allowing generic constraints on the T; e.g. "<any T extends Foo>
bar(T t) { // call some Foo method on t }" (ignore the syntax as it's
unimportant right now).  This way you can pass a value type that implements
an interface and not cause boxing.

On Wed, Jan 7, 2015 at 10:18 AM, Peter Levart <peter.levart at gmail.com>
wrote:

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