alternatives or complements to layers

[Ali Ebrahimi]

So only value boxes can implement interfaces? yes?

On Wed, Jan 7, 2015 at 8:51 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> In this case I'd expect the value type to get boxed and b = true.
>
> On Wed, Jan 7, 2015 at 12:07 PM, Ali Ebrahimi <ali.ebrahimi1781 at gmail.com>
> wrote:
>
>> 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
>>
>
>


-- 

Best Regards,
Ali Ebrahimi