Records -- current status

[Brian Goetz]

On 4/11/2018 7:46 PM, Stephen Colebourne wrote:
> On 16 March 2018 at 18:55, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 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.
> I'd like to agree, but I fear that what is proposed is too
> restrictive, and that it will be an attractive nuisance, especially
> given the large cliff edge (acknowledged by the docs as being a
> problem, but I worry "wait" for the improvements in classes may get
> overtaken by other more pressing concerns). The cliff egde is my
> biggest concern with records.

Yes, I would expect no other reaction.  And we are well aware of all of 
the issues you've raised.
> Having to redeclare all fields as constructor parameters when
> validating in a primary constructor would be unhelpful boilerplate -
> I'm not clear if that is still required.

No, that's been resolved.

>>   - 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.
> This is a big deal for me. We use additional fields all the time.

Yes, I understand your concern.

> The field could be hidden, say by a `cached` keyword to any method:
>
>    public cached String name() {
>      return firstName + " " + surname;
>    }

Yes, this is one of the middle grounds being considered.


> Those fields are not part of the state. They do not get used in equals
> or hashCode.

Yes, but the only way to prevent that is to prevent anyone from 
overriding equals/hashCode.  Which is equally unpopular.  Right now both 
are restricted, until we figure out which we are better off relaxing on.

> Fields being final by default with a non-final keyword seems OK,
> although perhaps `mutable record`

Can we please have a moratorium on syntax niggling until the semantics 
are nailed down?

>
> - Caching of hashCode() is vital for performance in certain cases
> where object used as a Map key. Not having this feature would prevent
> use of records in use cases where it really makes sense. This feature
> could be done for all immutable records, or it could be opt in. This
> is a must have for me.
Oh, well, if its a must have for you, we'll get right on it ;)

Seriously, we're well aware of this issue.

> - Records add the ability to convert data in and out in a standard way
> by a standard field name, exactly as needed by serialization
> frameworks and similar. However, there is currently no library
> proposal to provide an abstraction across records, JavaBeans and other
> classes representing data. I think it would be a mistake to introduce
> records without also introducing a library providing that abstraction
> into the java.base module.
>

The machinery for pattern matching will be that common link.  By 
providing a "principle deconstructor" (and matching it with a 
constructor of the same descriptor), you say to frameworks "here's how 
to scoop out my data, freeze it, and reconstitute me later."