[records] updates for Preview 9. hashCode
brian.goetz at oracle.com
Fri Jan 10 21:20:57 UTC 2020
No objection to further hashing the specification of the hash. Care to
post a proposed patch for the spec in j.l.Record?
On 1/9/2020 11:45 PM, John Rose wrote:
> If we don’t decide hashCode explicitly, I think we’ll back ourselves into
> a bad default decision. Should the hashing logic for r.hashCode() be specified
> in a portable manner? I say, “no”, since there’s no good portable solution.
> Objects.hash is portable, but other than that is a poor algorithm.
> Right now we don’t *specify* that we combine hashes using the base-31
> polynomial, but we *do* use that stupid old thing. This is plausibly conservative
> but it will get it into a worse spot than necessary. We can buy ourselves some
> time by putting weasel words into Record::hashCode (or its successor) and
> ObjectMethods::bootstrap. We can promise that the hashCode result
> depends (typically) on all components of the record, and on nothing else.
> We should also explicitly state that the method for combining the bits is
> subject to change, very much like we specify that the iteration order for
> Set.of and Map.of is subject to change, like this:
> Finally, for luck, we should add a pinch of salt to the hash function
> to keep users on their toes, like this:
> (It’s an implementation detail, but for now this combiner would be enough
> to buy us a better future: `(h,x) -> ((h*31)+x)^SALT`)
> If we aren’t cautious about this, I’m afraid that users will eventually discover
> that we are using the Objects.hash algorithm, we will be pressured to
> document it, and then we’ll be locked out from an easy improvement to
> records. It’s easier to introduce the salt before that happens.
> I don’t think we should even promise that the record hashCode is mixed
> from the hashCodes of the components. That’s TMI, and it boxes us in
> without telling the user anything useful. All we need to do is promise
> that a record type’s hashCode fulfills the Object contract, especially
> relative to the record’s equals method. No other promises, plus a warning
> that result is subject to change. And then rub some salt on it to keep
> it clean, as with Set.of and Map.of.
> — John
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the amber-spec-experts