Value type hash code (original) (raw)

Remi Forax forax at univ-mlv.fr
Wed Apr 11 18:27:22 UTC 2018

Hi Brian, in the l-world, you can have a reference or a value type in 'a' local, so acmp is defined as an identity check (if there is a value type on the left or on the right operand the result is false) not a substitution check.

Rémi

----- Mail original -----

De: "Brian Goetz" <brian.goetz at oracle.com> À: "daniel smith" <daniel.smith at oracle.com>, "David Simms" <david.simms at oracle.com> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net> Envoyé: Mercredi 11 Avril 2018 17:42:37 Objet: Re: Value type hash code

One of the operations we can name is ==.  I think the substitution check is the most reasonable interpretation of ==, but I don't really see how we can avoid recurring on .equals() for the equals() implementation. Otherwise, this will violate basic user expectations, such as:

value record StringBox(String s); I think values would be near-useless under such an interpretation of equals(). On 4/11/2018 10:13 AM, Dan Smith wrote:

On Apr 10, 2018, at 8:49 AM, David Simms <david.simms at oracle.com> wrote:

* Values containing references whose contents are mutable pose a problem, their hash code is only as stable as the contents of the whole object graph. There's some flexibility in how we name operations, but let's observe that there are two pairs of operations to consider: substitutable/substitutableHash: recur on value fields, use acmp on reference fields deepEquals/deepHash: recur on value fields, use 'equals' on reference fields I think my expectation has been that substitutable/substitutableHash would be the default behavior of equals/hashCode, with the capability for users to override this if they're confident it's safe. (And with the ability to fall back to the default behavior with System.identityHashCode or something similar.) > —Dan

More information about the valhalla-dev mailing list