Skip to main content

[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


On Tue, Dec 9, 2014 at 7:21 AM, Vladimir Piskarev <pisv@xxxxx> wrote:
Hi Vlad, 
 
Probably not, as far as I can see. Basically, we are trading off a little less computation in hashCode() for (potentially) a bit more computation in hash table lookup. I think it's not unreasonable: after all, namesake children of different element types are not that common. I have taken a look at JDT, and they do the same thing.
 
Why do you think it could be problematic? Do you have a particular use case in mind?
 
Best regards,
Vladimir
 
 
Hi!

Shouldn't Handle.hashCode use getElementType() too, in order to be consistent with Hash.equals?

        result = prime * result + getElementType().hashCode();

If I have children of different types and with same name, then putting them in a HashMap will create a bit of chaos...

regards,
Vlad


_______________________________________________
handly-dev mailing list
handly-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/handly-dev


Back to the top