A library for implementing equals and hashCode

[Stuart Marks]

>> 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.
> 
> I would disagree with this strongly. Use cases that require a *quality* hash
> code really need to use a proper hashing library like (bias alert) Guava's.
> It can produce quality results because its API is designed for that.

By "quality" hash code, do you mean a cryptographic hash? If so, then yes, 
that's really quite separate, and I'm not proposing supporting such a thing here.

Here's what I meant by "greater control". Liam's proposal talks about providing 
a hash reduce function implementation that is unspecified, allowing for the 
possibility of it changing in the future. Some applications will be fine with this.

Other applications might want to use this API for convenience, or cleaner code, 
or something, but which might want to use their own hash reduce function in 
order to preserve compatibility. They might want to replicate the hash function 
used in the past, or they might want to ensure that the hash function doesn't 
change out from under them in a future release. These applications might require 
"greater control" in the API of the hash reduce function.

On the other hand, maybe we don't need to support this use case, in which case 
the need for greater control goes away.

I'm not taking a position on this; I'm just mapping out the design space.

s'marks