Records -- current status

[Brian Goetz]

On 3/16/2018 4:45 PM, Remi Forax wrote:
>>   - Mutability and accessibility.  I'd like to propose an odd choice
>> here, which is: fields are final and package (protected for abstract
>> records) by default, but finality can be explicitly opted out of
>> (non-final) and accessibility can be explicitly widened (public).
> I think that record fields should be private thus only visible by the nestmates by default.
> I will have agree about being package visible by default before the introduction of nestmates, but now that we have nestmates, i do not see the need for having an unrelated class in the same package to see the implementation of a record.

The motivation for "package" is that this is the default in classes, so 
it would be one less thing that is different about records. Minimizing 
the differences between records and classes facilitates refactoring back 
and forth.  (Both refactoring directions are valuable; existing classes 
can be refactored to records to squeeze away the low-value code, but at 
some point, a record may cross the boundary of what records can do, and 
have to be refactored to a class (just as enums sometimes hit their 
limits and have to be refactored away.)  Minimizing the skew here helps.

> Having the field protected for abstract record is coherent with the fact that abstract record show too much detail of implementation and should not exist.

On further thought, these can be package or private too, since the 
subclass can call the getter.

>  - Core methods.  Records will get equals, hashCode, and toString.
>> There's a good argument for making equals/hashCode final (so they can't
>> be explicitly redeclared); this gives us stronger preservation of the
>> data invariants that allow us to safely and mechanically snapshot /
>> serialize / marshal (we'd definitely want this if we ever allowed
>> additional instance fields.)  No reason to suppress override of
>> toString, though. 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.)  I think the auto-generated
>> getters should be final too; this leaves arrays as second-class
>> components, but I am not sure that bothers me.
> i am lost here, if the record is final thus all the methods are final, no ??
>

So, if there is an implicit member implementation (like equals()), then 
an explicit implementation is like an override (even though its in the 
same class).  So in this context, final means not only "subclass may not 
override", but also means "record itself cannot provide explicit 
implementation."

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