Re: [handly-dev] Handle.hashCode inconsistency?

[Vlad Dumitrescu <vladdu55@xxxxxxxxx>]

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