Records -- current status

[Remi Forax]

> De: "Kevin Bourrillion" <kevinb at google.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 16 Mars 2018 23:36:53
> Objet: Re: Records -- current status

[...] 

>>> OK, but do you have an opinion on whether records should automatically acquire a
>>> clone() implementation?

>>> As much as possible we'll encourage all-final, array-free records that have no
>>> need to be cloned, but some number of records will go against that, and I guess
>>> it's better that they have clone() than that they don't. But my concern is:
>>> What does it do -- deep-clone arrays but shallow-clone everything else? Sounds
>>> problematic no matter which way you decide it.

>> Yes, that's the question. One possibility is just to always clone shallowly;
>> this is not as dumb as it sounds, since the fields are already exposed for
>> read, and therefore any deep mutability is already flapping in the wind.

> Okay, I guess that's the right move because you kinda want
> `record.clone().equals(record)`. But a user's assumption that `record.clone()`
> would deep-clone the array might be the entire reason they're using clone() at
> all. Oh well, it's not like we'd be making arrays awful for the first time.

There is no need to have a clone because clone == constructor(de-constructor()), 
And this is true for the serialization too, once you have a de-constructor and a constructor you can serialize the data in the middle, as you can do a shallow copy or a deep copy in the middle. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180320/6328a985/attachment.html>