Record design (and ancillary fields)

[Remi Forax]

----- Mail original -----
> De: "Daniel Latrémolière" <daniel.latremoliere at gmail.com>
> À: "amber-spec-comments" <amber-spec-comments at openjdk.java.net>
> Envoyé: Samedi 14 Avril 2018 05:43:40
> Objet: Record design (and ancillary fields)

> Isn't it possible to do for a record, like database design:

interesting question

> 
> - fields are, by default, read-write and not concerned by identity of
> the row/instance.
> 
> - one special field (primary key) has all constraints of the identity of
> the row/instance.
> 
> 
> For a record, that would signify that one field has to be marked
> __Identity. It will be the only field used in equals/hashCode methods of
> the record.
> 
> For satisfying constraints of identity (immutability), this field would
> be final and necessarily of a primitive type or value type (composite
> primary key). Given a value type can be scalarized in the class,
> restricting identity to only one field would not have real cost in instance.

I do not think we have to do something specific for supporting relational database mapping, 
the tools that does this mapping already relies on annotation processor or bytecode agent to change the user code (at least to track the changes),
so those tools can be updated to detect that a class is a record and provides the right equals/hashCode if those methods are not user defined.

> 
> 
> Just my point of view,
> 
> Daniel.
> 
> 
> PS: Given primitive/value type disallow cyclical references, this will
> prohibit StackOverflowException in equals/hashCode methods.

only if an equals on a value type that contains an object doesn't call equals on that object.

Rémi