> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Vendredi 16 Mars 2018 21:53:16 > Objet: Re: Records -- current status
> On 3/16/2018 4:45 PM, Remi Forax wrote: >>> - Mutability and accessibility. I'd like to propose an odd choice >>> here, which is: fields are final and package (protected for abstract >>> records) by default, but finality can be explicitly opted out of >>> (non-final) and accessibility can be explicitly widened (public). >> I think that record fields should be private thus only visible by the >> nestmates >> by default. >> I will have agree about being package visible by default before the >> introduction >> of nestmates, but now that we have nestmates, i do not see the need for >> having >> an unrelated class in the same package to see the implementation of a record. > The motivation for "package" is that this is the default in classes, so it > would > be one less thing that is different about records. Minimizing the differences > between records and classes facilitates refactoring back and forth. (Both > refactoring directions are valuable; existing classes can be refactored to > records to squeeze away the low-value code, but at some point, a record may > cross the boundary of what records can do, and have to be refactored to a > class > (just as enums sometimes hit their limits and have to be refactored away.) > Minimizing the skew here helps. Ok ! >> Having the field protected for abstract record is coherent with the fact that >> abstract record show too much detail of implementation and should not exist. > On further thought, these can be package or private too, since the subclass > can > call the getter. yes ! >> - Core methods. Records will get equals, hashCode, and toString. >>> There's a good argument for making equals/hashCode final (so they can't >>> be explicitly redeclared); this gives us stronger preservation of the >>> data invariants that allow us to safely and mechanically snapshot / >>> serialize / marshal (we'd definitely want this if we ever allowed >>> additional instance fields.) No reason to suppress override of >>> toString, though. Records could be safely made cloneable() with >>> automatic support too (like arrays), but not clear if this is worth it >>> (its darn useful for arrays, though.) I think the auto-generated >>> getters should be final too; this leaves arrays as second-class >>> components, but I am not sure that bothers me. >> i am lost here, if the record is final thus all the methods are final, no ?? > So, if there is an implicit member implementation (like equals()), then an > explicit implementation is like an override (even though its in the same > class). So in this context, final means not only "subclass may not override", > but also means "record itself cannot provide explicit implementation." Providing an explicit implementation is easier to understand. I agree that equals and hashCode should not be user-defined, if you want user-defined equals/hashCode, it means you do not want a record. Rémi
