Why Arrayish implements Cloneable?
pbenedict at apache.org
Wed Apr 27 21:14:27 UTC 2016
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.
On Wed, Apr 27, 2016 at 3:36 PM, Glen Peterson <glen at organicdesign.org>
> 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
> 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
More information about the valhalla-dev