| 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,VladimirMy 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,VladimirHi!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
_______________________________________________
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