> De: "Kevin Bourrillion" <kev...@google.com> > À: "Brian Goetz" <brian.go...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@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
