Records -- current status

[Brian Goetz]

>
>      - Extension.  The proposal outlines a notion of abstract record,
>     which provides a "width subtyped" hierarchy.  Some have questioned
>     whether this carries its weight, especially given how Scala
>     doesn't support case-to-case extension (some see this as a bug,
>     others as an existence proof.)  Records can implement interfaces.
>
>
> I also suggest we avoid abstract records. A reference to one may seem 
> like a proper record but it will behave badly with regard to equals(). 
> I don't see the upside compared to a common interface, and then you 
> don't have to have the novel parameterized extends clause.

The hackneyed example: consider the below as a subset of a typical 
"model an expression with a tree" hierarchy.  Of course, a real 
hierarchy would have a lot more classes.

     sealed interface Node;
     record ValNode(int value) extends Node;
     record VarNode(String name) extends Node;
     abstract record BinOpNode(Node left, Node right) extends Node;
     record PlusNode(Node left, Node right) extends BinOpNode(left, right);
     record MulNode(Node left, Node right) extends BinOpNode(left, right);

Obviously there might be some common behavior for binary operation nodes 
that can be factored up into BinOpNode.  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;
         }
     }

A client who is only interested in structural properties can match once 
on the abstract type, instead of matching explicitly on N effectively 
identical cases (and add more every time the hierarchy changes.)

>
> 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?  
(When we do sealed types, we're likely going to need a way to say 
non-sealed anyway.)

>
>      - Accessors.  Perhaps the most controversial aspect is that
>     records are inherently transparent to read; if something wants to
>     truly encapsulate state, it's not a record. Records will
>     eventually have pattern deconstructors, which will expose their
>     state, so we should go out of the gate with the equivalent.  The
>     obvious choice is to expose read accessors automatically.  (These
>     will not be named getXxx; we are not burning the ill-advised
>     Javabean naming conventions into the language, no matter how much
>     people think it already is.)  The obvious naming choice for these
>     accessors is fieldName().  No provision for write accessors;
>     that's bring-your-own.
>
>
> Method and field named identically is a slight concern. If we gain 
> field references using the same syntax as method references there 
> would probably be no way to refer to such a field. I'm pretty sure 
> this is not worth worrying about though.

I have a story for disambiguating field references...

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180316/3591ed6c/attachment.html>