search

MedwynLiang / google-collections

Automatically exported from code.google.com/p/google-collections
Apache License 2.0
0 stars 0 forks source link

Add Objects.hashCode overloads for Object + all primatives #95

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
 It would be useful to have the behaviour for computing hashcodes as recommended in Effective 
Java Item 8 included as a library function.  See 
http://java.sun.com/developer/Books/effectivejava/Chapter3.pdf

This would include Objects.hashCode(Object) (returning o == null ? 0 : 
o.hashCode() ), and 
overloads for primatives:

bool: return param ? 0 : 1;
byte, char, short, int:  return (int) param;
long: return (int)(param ^ (param >>> 32));
float: return Float.floatToIntBits(param);
double: long l = Double.doubleToLongBits(param); return (int)(l ^ (l >>> 32));

Original issue reported on code.google.com by Ben.Lings on 25 Aug 2008 at 7:12

GoogleCodeExporter commented 9 years ago 
Objects.hashCode() will do most of this for you.  For the rest, it would be 
possible
to add methods (though not overloads), but it's not immediately clear to me what
benefit that would provide.

Objects.hashCode() does almost exactly what you want for arrays of objects.  
Due to
autoboxing, double values are converted to Double instances, etc.  
Double.hashCode()
is defined just as Effective Java recommends.  A sample of the other Number 
classes
suggests the same is true there.  (Boolean is slightly different from EJ, but 
it's
likely that that decision was made for a reason and that, even if not, most 
users
won't need to guarantee that 0 and 1 are the two values chosen.)  Finally,
Objects.hashCode() treats null as an object with a hash code of zero.

The primary difference from what you appear to be asking for (correct me if I'm
wrong) is that Objects.hashCode() operates on an array of objects.  This means 
that
Objects.hashCode(x) == 31 + x.hashCode(), while I believe that what you want is
Objects.hashCode(x) == x.hashCode().  Providing single-argument overloads for
Objects.hashCode() with the desired behavior would make calls to 
Objects.hashCode(x)
ambiguous between the varargs and single-argument forms.

A change in naming (Objects.singleObjectHashCode() or something shorter) would 
solve
this problem, but I'm curious as to whether Objects.hashCode(x) == x.hashCode() 
is a
hard requirement or whether it was just the logical thing to do for a 
single-argument
method.  Given that Objects.hashCode() already handles primitive hash codes 
properly,
is there still a need for the overloads?

Original comment by cpov...@google.com on 25 Aug 2008 at 8:07

GoogleCodeExporter commented 9 years ago 
My main reason for requesting this is to prevent unnecessary autoboxing when 
calculating the hashCode for a 
primitive.  The ideal place to put this would be on the primitive wrapper 
classes (see 
http://smallwig.blogspot.com/2007/11/minor-api-fixes-for-jdk-7.html). However, 
without that possibility,  
can I change my request to be to add a new helper class called Primitives.  
This would have the overrides for 
hashCode(P) for primitives (as listed above).

This class could also have equals(P,P) methods for all primitives, that use 
{Float,Double}.compare or == as 
appropriate (as recommended by Item 8 in Effective Java).

Original comment by Ben.Lings on 25 Aug 2008 at 8:51

GoogleCodeExporter commented 9 years ago 
+1 to standardized primitive hashing functions

Re #2: "This class could also have equals(P,P) methods for all primitives, that 
use
{Float,Double}.compare"

Why not just expose "compare" methods for the primitives then?

Original comment by estebis...@gmail.com on 3 Sep 2008 at 7:53

GoogleCodeExporter commented 9 years ago 
The Comparators class already has compare methods for the primitives.

Original comment by jared.l....@gmail.com on 4 Sep 2008 at 12:45

GoogleCodeExporter commented 9 years ago 
Right-o. Forgot about that as I generalized his "equals" request...

Back to the main issue in the bug, the hashCode methods would be nice.

Original comment by estebis...@gmail.com on 4 Sep 2008 at 2:42

GoogleCodeExporter commented 9 years ago 
I want to get out of the primitives business in this library.  There are *many*
primitive-oriented features that are desirable but they should go in a
primitive-oriented library.  Sorry.

Original comment by kevin...@gmail.com on 29 Dec 2008 at 8:43