Along the lines of the previous mail, people have and will ask "why
can't I redefine equals/hashCode". And the answer has two layers:
- The constraints on equals/hashCode are stronger for records, and
users might inadvertently violate them. (They can be specified in the
overrides of equals/hashCode in AbstractRecord, so there at least can be
a place where this specification lives, even if no one reads it.)
- In conjunction with ancillary fields, the constraints are sure to be
violated, whether inadvertently and deliberately.
Let's take a look at what sorts of modifications to equals/hashCode
would be OK, should we decide to relax this restriction. Equality
should still derive from the record's state, but there might be
acceptable variations.
Would it be OK to _widen_ the definition of equality, by ignoring a
component of the record?
This is an example of what Gunnar asked for, which is to restrict
equality to the primary key fields:
record PersonEntity(int primaryKey, String name, int age) {
// equality based only on primaryKey
}
Is this OK? Well, let's look at our model:
- Does ctor(dtor(c)) == c? Yes.
- if S1==S2, does ctor(S1) == ctor(S2)? Yes.
- For equal instances, does mutating them in the same way yield equal
instances? Yes.
- For equal instances, does calling the same method on both with the
same parameters yield equivalent results? No.
So, if p1 == p2, we cannot rely on p1.age() == p2.age(), so this fails
the requirements of our pseudo-formal model. (Assuming our model is the
right one.)
So, how would we feel about that? Two records that are equals() to each
other, but not substitable?
A more subtle version of this would be to consider all components, but
use a more inclusive notion of equality for that field, such as
comparing array components by contents.
record Numbers(int[] numbers) {
// equality based on Arrays.equals()
}
- Does ctor(dtor(c)) == c? Yes.
- Do equal state vectors produce equal records? Yes.
- Do identical mutations on equal records produce equal records? Yes.
- Does identical operations on equal records produce equal results?
Almost...
The Almost qualification can be seen here:
int[] a1;
int[] a2 = copyOf(a1);
Numbers r1 = new Numbers(a1), r2 = new Numbers(a2);
boolean same = a1.numbers().equals(a2.numbers())
The accessor will yield up the array references, which will not be
equals() to each other. This is essentially the same problem as above.
You get a similar result if your record represents something like a
rational number and you don't normalize to lowest terms in the
constructor; then you can have q1 equal q2, but q1.numerator() !=
q1.numerator().
Are any of these variations compelling enough to suggest we've got the
wrong model?
On 3/16/2018 2:55 PM, Brian Goetz 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.
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".
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.
- Concrete records are final. Relaxing this adds complexity to the
equality story; I'm not seeing good reasons to do so.
- 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.)
- Static fields. Static fields seem harmless.
- 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.
- 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).
- 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.
- 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.
