<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 16, 2018 at 2:28 PM, Brian Goetz <span dir="ltr"><<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><br>But also, there are
    times when matching against the abstract type makes sense too.  For
    example, if you want to traverse the tree and perform structural
    operations (say, detect if a tree contains a reference to the
    variable "x"), matching on abstract records is pretty useful:<br>
    <br>
        boolean containsVar(Node node, String name) {<br>
            return switch (node) {<br>
                case VarNode(String s) -> s.equals(name);<br>
                case BinOpNode(var left, var right) ->
    containsVar(left, name) || containsVar(right, name);<br>
                default -> false;<br>
            }<br>
        }<br></div></blockquote><div><br></div><div>Am I correct that if BinOpNode is an interface there will be a way for it to specify how it destructures so that it can get this effect also - and it's just that records are neat because they know how to destructure for free?</div><div><br></div><div>We want people to be solid on the fact that two records with all the same field values are always equals(), and then they may apply that view to an abstract record type where it doesn't hold true.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On the other hand. As much as I want everyone to stick
              to immutable records as much as possible, it seems very
              costly to me to have to introduce a new keyword for "not
              final", and have users keep track of which things have
              which defaults. Let this just be "best practice", like it
              already is for regular fields (make them final unless you
              have good reason not to).</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Pretend we already had non-final.  Does that change your
    inclination?</div></blockquote><div><br></div><div>I don't think so? The reversed default behavior feels like arbitrary difference from regular fields (again, I do <i>want</i> to encourage finalness of record fields...). Would we permit the "not final" keyword on interface fields too? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.)<br>
            </blockquote>
            <div><br>
            </div>
            <div>People just really need to not use arrays anymore, and
              especially not with records. imho we should have added
              immutable List and ImmutableIntArray etc. classes a very
              long time ago. I know we won't now due to our value type
              aspirations. In the meantime we're in a weird place.
              Arrays are completely terrible except as
              micro-optimizations to be used with great care.</div></div></div></div></blockquote></span>
    OK, but do  you have an opinion on whether records should
    automatically acquire a clone() implementation?  <br></div></blockquote><div><br></div><div>As much as possible we'll encourage all-final, array-free records that have no need to be cloned, but some number of records will go against that, and I guess it's better that they have clone() than that they don't. But my concern is: What does it do -- deep-clone arrays but shallow-clone everything else? Sounds problematic no matter which way you decide it.<br class="gmail-Apple-interchange-newline"></div></div><br clear="all"><div><br></div>-- <br><div class="m_5836351202611258626gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div>
</div></div>