Records -- current status

[Kevin Bourrillion]

On Fri, Mar 16, 2018 at 2:28 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

>
> 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:
>
>     boolean containsVar(Node node, String name) {
>         return switch (node) {
>             case VarNode(String s) -> s.equals(name);
>             case BinOpNode(var left, var right) -> containsVar(left, name)
> || containsVar(right, name);
>             default -> false;
>         }
>     }
>

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?

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.

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).
>
>
> Pretend we already had non-final.  Does that change your inclination?
>

I don't think so? The reversed default behavior feels like arbitrary
difference from regular fields (again, I do *want* to encourage finalness
of record fields...). Would we permit the "not final" keyword on interface
fields too?

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.)
>>
>
> 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.
>
> OK, but do  you have an opinion on whether records should automatically
> acquire a clone() implementation?
>

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.


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180316/060092f1/attachment.html>