A library for implementing equals and hashCode
cushon at google.com
Wed Apr 24 22:52:10 UTC 2019
Thanks for the background! I added your links to the doc.
On Tue, Apr 23, 2019 at 6:06 PM Stuart Marks <stuart.marks at oracle.com>
> I think the Odersky article about Java equals() methods that was referred
> elsewhere is this one:
I think the crux of this is the effect on substitutability. I'm not sure
we're going to be
able to provide a single opinionated solution to writing equals methods on
Winning here might be making it possible (and reasonably ergonomic) to
common approaches to this problem.
> Finally, I agree that the hash function should be left unspecified, but if
> has a well-known and predictable implementation, it will shortly become
> the "de
> facto" specification and will be very difficult to change in the future.
> therefore in favor of more aggressive approaches to create a defensible
> for future changes. This might include randomization, perhaps on by
> perhaps opt-out, or possibly something else.
As mentioned in the doc we've had good results randomizing the iteration
hash-based containers at Google, but we're only doing it in tests.
Other languages have had success with being more aggressive, for example go
always randomizes the iteration order of maps.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the amber-spec-experts