Kevin say:
However, it would be very sad if it does not solve a second problem at
the same time, because it can. Even Java developers who are content
with the performance foibles of their existing "value-based classes"
are constantly irritated by the burden and bug-prone nature of
writing/maintaining such classes.
We have two choices in front of us regarding equality on value types:
1. What does `==` on values do? Choices include a bitwise comparison,
a componentwise comparision (identical to bitwise unless there are float
members), or invoking the `equals()` method.
2. What is the default for the `equals()` method? The obvious choice
is a componentwise comparision, but Kevin has (strongly) suggested we
consider a deep comparison, calling .equals() on any reference members.
(Note that the two choices collapse to the same thing when there are no
reference members.)
For values whose members are value-ish objects themselves (e.g., String,
Optional, LocalDateTime), the deep-equals is obviously appealing -- a
tuple of (int, date) makes total sense to compare using .equals() on the
date. On the other hand, for values whose members are references to
mutable things (like lists), it's not as obvious what the right default is.
So, Kevin -- please make your case! Please share your experience with
tools like AutoValue, and if you can, data on how frequently (and why)
equals() is underridden on auto values in the Google codebase?
