Issue 95 in google-collections: Add Objects.hashCode overloads for Object + all primatives
codesite...@google.com
http://code.google.com/p/google-collections/issues/detail?id=95
New issue report by Ben.Lings:
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));
Issue attributes:
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
codesite...@google.com
http://code.google.com/p/google-collections/issues/detail?id=95
Comment #1 by cpov...@google.com:
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?
codesite...@google.com
http://code.google.com/p/google-collections/issues/detail?id=95
Comment #2 by Ben.Lings:
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).