alternatives or complements to layers
Vitaly Davidovich
vitalyd at gmail.com
Wed Jan 7 16:49:54 UTC 2015
Can you elaborate a bit on what the issue is?
On Wed, Jan 7, 2015 at 11:47 AM, 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
>>>
>>>
>>>
More information about the valhalla-dev
mailing list