Joshua Bloch wrote:
Joe,
I'm not sure I like this idea. My one experience with forcing an
array method to do double duty as varargs method was a disaster. The
method was Arrays.asList, and the result was Puzzler # 7 from "The
Continuing Adventures of Java™Puzzlers: Tiger Traps." Here it is:
*7. “Fib O’Nacci”*
public class Fibonacci {
private static final int LENGTH = 7;
public static void main(String[] args) {
int[] fib = new int[LENGTH];
fib[0] = fib[1] = 1; // First 2 Fibonacci numbers
for (inti = 2; i < LENGTH; i++)
fib[i] = fib[i -2] + fib[i -1];
System.out.println(Arrays.asList(fib));
}
}
The main moral of the puzzle was:
Use varargssparingly in your APIs
•It can hide errors and cause confusion
•This program wouldn't compile under 1.4
Arrays.hashCode, equals, and toString are already overloaded out the
wazoo; adding varargs to the mix could be deadly. Also, Arrays is not
the place where people would go looking for what is essentially a
hashing utility. So I'm not in favor of varargifying the existing
methods in Arrays, but I am in favor of adding a convenience method
like this somewhere:
/**
* Generates a hash code for a sequence of input values. The hash
code is
* generated as if all the input values were placed into an array,
and that
* array were hashed by calling {...@link Arrays#hashCode(Object[])}.
* <p/>
* <p>This method is useful for implementing {...@link
Object#hashCode()} on
* objects containing multiple fields. For example, if an object
that has
* three fields, {...@code x}, {...@code y}, and {...@code z}, one could
write:
* <pre>
* @Override public int hashCode() {
* return Objects.hashCode(x, y, z);
* }
* </pre>
* <b>Warning: When a single object reference is supplied, the
returned
* value does not equal the hash code of that object
reference.</b> This
* value can be computed by calling {...@link #hashCode(Object)}.
*/
public static int hash(Object... components) {
return Arrays.hashCode(components);
}
Viewed in isolation, it's simple, straightforward, and will help
people write high quality hashCode methods. I don't think Objects is
a bad place for it, but you could put it is a "hash utility" class if
we wrote such a thing.
Okay; unless and until a hash utility is added somewhere, this
hash(Object ...) can live in Objects.
-Joe
