Why Arrayish implements Cloneable?

[Paul Benedict]

I had the same thought as Glen. If the JDK has a contract itself must meet
with primitive types, then introducing something like a PrimitiveArrayish
(implements Serializable & Cloneable) makes sense to me. Then Arrayish
itself can be "pure" and a nice building block for other use cases.

Cheers,
Paul

On Wed, Apr 27, 2016 at 3:36 PM, Glen Peterson <glen at organicdesign.org>
wrote:

> Adding Serializable (and/or Cloneable) to Arrayish makes it harder to
> extend.  Not every implementation of Arrayish necessarily wants to
> allow serialization or cloning.  Can you have an Arrayish interface
> and some sub-interface like SerializableArrayish extend it for your
> purposes?  Then people can easily extend Arrayish without the added
> overhead.
>
> What about making the type of your new primitive array Arrayish &
> Serializable?  I haven't used intersection types in Java so that may
> be more trouble than it's worth, but I thought I'd throw it out there.
>
> On Wed, Apr 27, 2016 at 4:06 PM, John Rose <john.r.rose at oracle.com> wrote:
> > A2.0 entails splitting current types of the form <any T> T[] in into
> interfaces and implementations.
> > That is, in a future VM we will have polymorphic, generic interfaces
> (Arrayish, etc.) and built-in
> > linearly stored implementations of the same, what we are familiar with
> as "classic arrays".
> >
> > We *could* deem that either or both of the marker interfaces
> Serializable and Cloneable on all T[]
> > are, in fact, implementation artifacts, limited to classic arrays, and
> not pushed into the generic APIs.
> >
> > In fact, on second thought, we *should* do this for Cloneable, since it
> is not an API.  The generic
> > method <any T> clone()T[] is part of the array API, but it is not at all
> dependent on Cloneable.
> >
> > What about Serializable?  Perhaps we can mandate (another way) that all
> Arrayish's will be
> > serializable, without putting in the marker interface.  But I think
> that's a losing battle.
> >
> > It might in fact be the case that many (or even all?) array
> implementations would chose to
> > include both Cloneable and Serializable, but that's not necessarily true
> in all possible worlds.
> >
> > — John
> >
> > P.S. I was reading Smullyan on modal logic last night, hence the modal
> connective in that
> > last statement.
> >
> > On Apr 27, 2016, at 7:45 AM, Brian Goetz <Brian.Goetz at Oracle.COM> wrote:
> >>
> >> Currently, the array classes (int[].class, String[].class) are totally
> magical and spring into existence when referenced.  They all happen to have
> some common supertypes (Cloneable, Serializable).
> >>
> >> This patch moves things forward incrementally (see John's talk on
> Arrays 2.0, http://medianetwork.oracle.com/video/player/1785452137001) by
> providing all arrays with a real supertype, Arrayish, which exposes element
> accessors.  This allows, for example, abstraction over array types (<T
> extends Arrayish>), as well as being a precursor to some other cool stuff.
> >>
> >> On 4/27/2016 10:32 AM, Paul Benedict wrote:
> >>> Oh, okay ... so basically when you let the native "any" type be boxed,
> you're exposing the same functionality through an interface.
> >>>
> >>> Cheers,
> >>> Paul
> >>>
> >>> On Wed, Apr 27, 2016 at 9:25 AM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
> >>>
> >>>    Because array types (int[], String[]) *already* implement
> >>>    Cloneable and Serializable.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>    On 4/27/2016 10:18 AM, Paul Benedict wrote:
> >>>
> >>>        I only ask because Cloneable is typically looked at as a poor
> >>>        mechanism for
> >>>        duplicating objects. That's the sentiment, anyway, widely
> >>>        popularized by
> >>>        the Effective Java book.
> >>>
> >>>        Cheers,
> >>>        Paul
> >>>
> >>>
> >>>
> >>
> >
>
>
>
> --
> Glen K. Peterson
> (828) 393-0081
>
> 11110 000
> 10 011111
> 10 011001
> 10 000010
>