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