alternatives or complements to layers

[Vitaly Davidovich]

This is how this works in .NET; not saying it has to be the same in java,
but i find their treatment fairly sound.

Assigning a value type to an interface directly boxes; the box implements
the same interface and forwards the calls to the value type itself.  To
avoid boxing yet work with interfaces, they allow generics to be
constrained; when you specify the type as a value type for said generic
type, there's no boxing - the CLR specializes the type internally.

Sent from my phone
On Jan 7, 2015 12:48 PM, "Ali Ebrahimi" <ali.ebrahimi1781 at gmail.com> wrote:

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