<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <blockquote type="cite" cite="mid:626263129.22463743.1769024919495.JavaMail.zimbra@univ-eiffel.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
        <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;">But
            also, you pay a big complexity tax when the new concept is
            almost like but can't quite fully meet up with the old
            concept; it again means that refactoring from record
            <--> carrier comes with a significant sharp edge, and
            this is a big warning signal.  So we would need a much
            stronger reason than "hmm, kind of like it better this way"
            to choose this divergent path.  So far I'm not seeing it?</blockquote>
          <div><br>
          </div>
          <div>There is a big sharp edge between a record and a class
            which is due to mutability, this is true inside the class
            but also outside, the user code when something is mutable or
            not is quite different .So refactoring from a mutable class
            to to an unmodifiable record is a not battle we should be
            interested in.</div>
        </div>
      </div>
    </blockquote>
    <br>
    Just because carrier class state _can_ be mutable, doesn't mean it
    _must_ be.  So you're skipping over the interesting case, which is:<br>
    <br>
        record R(int x, ...) { }<br>
    <br>
    and<br>
    <br>
        final class R(int x, ...) { private final component int x; ...
    }  // not equivalent to above!  <br>
    <br>
    In your model, the class version of R is painful to write, because
    you have to write equals, hashCode, and toString that delegate to
    each of the components.  But that's not even the main point; it is
    that while there is no theoretical distinction between a record and
    a final class all of whose components are backed by final component
    fields, there is a big and hard-to-explain discontinuity when you
    start from either of those and try to refactor to the other.  <br>
    <br>
    But you are still not justifying your preference; WHY is
    identity-based equality the *obviously right* choice for carriers? 
    Be semantic please!  Tell me what you think a carrier *means*.  
  </body>
</html>