[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [handly-dev] Handle.hashCode inconsistency?
|
Oh, I see. It's a very good rule, indeed. But we can draw an allusion: getElementType() is akin to getClass() -- in fact, default implementation (expected to be used in 99% cases) just returns getClass() -- and as a rule, getClass() is used in equals but not in hashCode. Here is a sample generated by Eclipse:
public class X
{
private int x;
@Override
public int hashCode()
{
final int prime = 31;
int result = 1;
result = prime * result + x;
return result;
}
@Override
public boolean equals(Object obj)
{
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
X other = (X)obj;
if (x != other.x)
return false;
return true;
}
}
And thanks for bringing this to attention! Those equals/hashCode can be rather tricky, so a double check certainly doesn't hurt :-)
Hi!
You are right, it's not necessary to use the element type in hashCode. I took to the rule to always use the same fields in equals and hashCode, to be sure it's as it should be (I had some problems at one time when I didn't), but it's a "better safe than sorry" rule.
I think I am still getting used to the Handly idioms :-)
best regards,
Vlad
