<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <blockquote type="cite" cite="mid:1481652515.22449673.1769020576885.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;"><br>

            So there are two stabled, principled alternatives:<br>

            <br>

             - Just don't ever try to derive equals and hashCode <br>

             - Derive equals and hashCode similarly as for records<br>

            <br>

            And of course, the first means that records cannot be

            considered special cases of carriers.  So the latter seems a

            forced move. </blockquote>

          <div><br>

          </div>

          <div>I still think there is value to consider that a carrier

            class is an abstract specification that just say that it can

            be constructed/deconstructed but equals/hashCode are user

            defined.</div>

          <div><br data-mce-bogus="1">

          </div>

          <div>When you use only pattern matching, you do not really

            need equals/hashCode to be defined, you recursively

            pattern-match until you have primitive values.</div>

          <br>

        </div>

      </div>

    </blockquote>

    <br>

    I agree that it is a valid question to ask: "does declaring a state

    description for a carrier class influence the Object behaviors." 

    And I do understand why you are attracted to this; once we leave the

    strict representation constraints of records, it feels somewhat less

    anchored, primarily because "mutability."  <br>

    <br>

    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?

  </body>

</html>