Why Arrayish implements Cloneable?
Glen Peterson
glen at organicdesign.org
Wed Apr 27 20:36:27 UTC 2016
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
More information about the valhalla-dev
mailing list