<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 3/16/2018 4:45 PM, Remi Forax wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1214486812.2461440.1521233153357.JavaMail.zimbra@u-pem.fr">
      <blockquote type="cite" style="color: #000000;">
        <pre wrap=""> - 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 wrap="">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.  <br>
    <br>
    <blockquote type="cite"
      cite="mid:1214486812.2461440.1521233153357.JavaMail.zimbra@u-pem.fr">
      <pre wrap="">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.<br>
    <br>
    <blockquote type="cite"
      cite="mid:1214486812.2461440.1521233153357.JavaMail.zimbra@u-pem.fr"> -
      Core methods.  Records will get equals, hashCode, and toString.
      <blockquote type="cite" style="color: #000000;">
        <pre wrap="">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 wrap="">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."<br>
    <br>
  </body>
</html>