alternatives or complements to layers

Brian Goetz brian.goetz at oracle.com
Wed Jan 7 16:47:15 UTC 2015


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


More information about the valhalla-dev mailing list