<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>