Records -- current status

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180320/1292be62/attachment.html>