j.ul.Objects follow-up: methods for var-argification?

[Rémi Forax]

Le 12/10/2009 19:25, Joseph D. Darcy a écrit :
> 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

In that case, we can also add some methods hash that avoid create an array
for let say 2 to 5 arguments:
hash(Object, Object), hash-Object, Object, Object), 
hash(Object,Object,Object,Object)
and hash(Object,Object,Object,Object,Object).

Rémi