On 4/24/19 3:52 PM, Liam Miller-Cushon wrote:
Finally, I agree that the hash function should be left unspecified, but if
it
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. I'm
therefore in favor of more aggressive approaches to create a defensible
space
for future changes. This might include randomization, perhaps on by default,
perhaps opt-out, or possibly something else.
As mentioned in the doc we've had good results randomizing the iteration order
of
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.
Heh, I guess I was being a bit too oblique. :-)
The Java 9+ unmodifiable collections (Set.of, Map.of) have randomized iteration
order. There's been a bunch of discussion about this, which I don't think we
need to repeat here. What's relevant here, though, is that it has enabled us to
make internal reorganizations to the data structures (and also to the
randomization scheme) with impunity, as we're pretty well assured that
applications cannot have any dependency on the iteration order. This is what I
meant by "defensible space for future changes."
Similarly, if the hashcode library is going to be supplying a function that
we'll want to change in the future, we'll need to take steps to ensure that
applications don't depend on the initial implementation. However, I can see that
some applications might want greater control over the actual hash function, so
that capability probably will need to be provided through the API somehow.
s'marks
