alternatives or complements to layers

[Brian Goetz]

(And this is more or less consistent with what we've been envisioning.)

On 1/7/2015 1:01 PM, Vitaly Davidovich wrote:
> 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
> <mailto: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
>     <mailto: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 <mailto: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 <mailto: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 <mailto: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
>