alternatives or complements to layers

Ali Ebrahimi ali.ebrahimi1781 at gmail.com
Wed Jan 7 17:07:26 UTC 2015


Hi,
if value types can implement Interfaces how  we can recognize interface
FooAble is value type or reference type?

FooAble x = test();
boolean b = x instanceof Object;

b?



On Wed, Jan 7, 2015 at 8:17 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Ideally, yes.
>
> Where we don't currently have a story is the interaction of value types,
> interfaces, and bounds.  It seems natural enough to say (from a source-code
> perspective):
>
> value class Bar implements FooAble { ... }
>
> and
>
> <T extends FooAble> void foo(T t)
>
> but these don't necessarily mean exactly what you might think at first, so
> there are many details in which devils lurk.
>
>
>
> On 1/7/2015 11:41 AM, Vitaly Davidovich wrote:
>
>> I really hope we get proper generic constraints and not have to write
>> instanceof checks for such cases.  Also, I want it to be clear from
>> looking
>> at the method definition that it really expects a SomeInterface type
>> internally and not just any plain T.  Think of declaring generic methods
>> in
>> an interface that are constrained to be SomeInterface (or subtype) -- this
>> needs to be visible purely from interface, without looking at impl.
>>
>> On Wed, Jan 7, 2015 at 11:36 AM, Peter Levart <peter.levart at gmail.com>
>> wrote:
>>
>>  On 01/07/2015 04:39 PM, Maurizio Cimadamore wrote:
>>>
>>>
>>>> On 07/01/15 15:37, Peter Levart wrote:
>>>>
>>>>  It was said that an option is for all value types (including
>>>>> primitives)
>>>>> to get 3 Object methods (hashCode, equals, toString). So at least
>>>>> println
>>>>> is doable.
>>>>>
>>>>>  Right - I was speaking more generally of all methods which are
>>>> overloaded
>>>> on the parameter type with Object, int, long, ...
>>>>
>>>> Maurizio
>>>>
>>>>
>>> Depends on how value types interact with interfaces. I think that the in
>>> following idiom, for example:
>>>
>>>
>>> interface SomeInterface {  method() { ...  } }
>>>
>>>
>>> <any T> void doSomething(T arg) {
>>>      if (arg instanceof SomeInterface) {
>>>          ((SomeInterface)arg).method(); ...
>>>      }
>>> }
>>>
>>>
>>> It would not be necessary to box the 'arg' (in specializations where T is
>>> value type) just to invoke an interface method on it. The expression "arg
>>> instanceof SomeInterface" could be evaluated at specialization time and
>>> replaced with either "true" or "false".
>>>
>>> The cast ((SomeInterface)arg) could be replaced during specialization
>>> with
>>> either "throw CCE" or no-op.
>>>
>>> So value types could expose common behaviour (like Formattable, etc...)
>>> even to "any T" methods without resorting to boxing (which specialization
>>> is trying to avoid).
>>>
>>>
>>>
>>> Peter
>>>
>>>
>>>


-- 

Best Regards,
Ali Ebrahimi


More information about the valhalla-dev mailing list