alternatives or complements to layers

Vitaly Davidovich vitalyd at gmail.com
Wed Jan 7 17:21:45 UTC 2015


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
>


More information about the valhalla-dev mailing list