<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>À: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Envoyé: </b>Vendredi 16 Mars 2018 21:53:16<br><b>Objet: </b>Re: Records -- current status<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><br><div class="moz-cite-prefix">On 3/16/2018 4:45 PM, Remi Forax wrote:<br></div><blockquote cite="mid:1214486812.2461440.1521233153357.JavaMail.zimbra@u-pem.fr"><blockquote style="color: #000000;"><pre> - 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).
</pre></blockquote><pre>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.</pre></blockquote><br>
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. </blockquote><div><br></div><div>Ok !<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><br><blockquote cite="mid:1214486812.2461440.1521233153357.JavaMail.zimbra@u-pem.fr"><pre>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. </pre></blockquote><br>
On further thought, these can be package or private too, since the
subclass can call the getter.</blockquote><div><br></div><div>yes !<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><br><blockquote cite="mid:1214486812.2461440.1521233153357.JavaMail.zimbra@u-pem.fr"> -
Core methods. Records will get equals, hashCode, and toString.
<blockquote style="color: #000000;"><pre>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.
</pre></blockquote><pre>i am lost here, if the record is final thus all the methods are final, no ??
</pre></blockquote><br>
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."</blockquote><div><br></div><div>Providing an explicit implementation is easier to understand.<br data-mce-bogus="1"></div><div>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.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><br><br></blockquote></div></div></body></html>