Records -- current status

[Remi Forax]

Hi Brian,

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 16 Mars 2018 19:55:19
> Objet: Records -- current status

> There are a number of potentially open details on the design for
> records.  My inclination is to start with the simplest thing that
> preserves the flexibility and expectations we want, and consider opening
> up later as necessary.
> 
> One of the biggest issues, which Kevin raised as a must-address issue,
> is having sufficient support for precondition validation. Without
> foreclosing on the ability to do more later with declarative guards, I
> think the recent construction proposal meets the requirement for
> lightweight enforcement with minimal or no duplication.  I'm hopeful
> that this bit is "there".

I agree, having the user write their own write accessor is a fine idea.
Users will still have to write the doc manually, and maintains the encapsulation correctly but in term of design, this allow us to move forward by separating the concept of record and the concept of precondition guard. Kudo to you for that ! 

> 
> Our goal all along has been to define records as being “just macros” for
> a finer-grained set of features.  Some of these are motivated by
> boilerplate; some are motivated by semantics (coupling semantics of API
> elements to state.)  In general, records will get there first, and then
> ordinary classes will get the more general feature, but the default
> answer for "can you relax records, so I can use it in this case that
> almost but doesn't quite fit" should be "no, but there will probably be
> a feature coming that makes that class simpler, wait for that."
> 
> 
> Some other open issues (please see my writeup at
> http://cr.openjdk.java.net/~briangoetz/amber/datum.html for reference),
> and my current thoughts on these, are outlined below. Comments welcome!
> 
>  - 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.

Kotlin does not support abstract data class too.
And we can still add abstract record later.

> 
>  - Concrete records are final.  Relaxing this adds complexity to the
> equality story; I'm not seeing good reasons to do so.

i fully agree.

> 
>  - Additional constructors.  I don't see any reason why additional
> constructors are problematic, especially if they are constrained to
> delegate to the default constructor (which in turn is made far simpler
> if there can be statements ahead of the this() call.) Users may find the
> lack of additional constructors to be an arbitrary limitation (and
> they'd probably be right.)

i agree.

> 
>  - Static fields.  Static fields seem harmless.

a static field is never harmless, eager initialization and being a root for the GC can make them dangerous, but we should support them.

> 
>  - Additional instance fields.  These are a much bigger concern. While
> the primary arguments against them are of the "slippery slope" variety,
> I still have deep misgivings about supporting unrestricted non-principal
> instance fields, and I also haven't found a reasonable set of
> restrictions that makes this less risky.  I'd like to keep looking for a
> better story here, before just caving on this, as I worry doing so will
> end up biting us in the back.

data class <=> no hidden states, so no secondary instance fields.
And again, we can add them later, if needed.

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

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. 

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

Again, no write accessor by default is a clever idea !

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

Overall, i think this proposed design is sound and great.
I've no objection to its inclusion in a future release. 

cheers,
Rémi