Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [handly-dev] Handle.hashCode inconsistency?
Well, after this discussion, I would say that we should fix that place in the example model, as it creates a bad precedent for adopters. Generally, any extra fields should be accounted both in equals and hashCode -- you are absolutely right.
 
Vlad, could you please raise a bug for it against Handly Examples?
 
Thanks,
Vladimir
 
 
My starting point was from the more detailed implementation. For the example model, FooDef uses the function's arity as an extra field (we could also add the type signature, if that was available) and it is only used in equals. The question is whether it should be used in hashCode too. In practice, there will only be a handful of elements that will share the same name, so you are right that it might not be an issue. There will be some hash collisions in any case.

regards,
Vlad


On Tue, Dec 9, 2014 at 11:15 AM, Vladimir Piskarev <pisv@xxxxx> wrote:
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


_______________________________________________
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