Paul Phillips wrote:
On Thu, Jun 11, 2009 at 01:03:59PM -0700, Landei wrote:
> This is not only a theoretical question, as Range already *uses* an
> equals method as described. So I wrote a little test to count the
> clashes for Range (please correct me if I didn't understood the
> algorithm correctly):
For sure that trait is highly experimental (I just have way too much
code in local branches and am attempting to work some of it into trunk.)
That said, I'm not sure what you think is happening in there, but who
cares if unequal ranges have equal hashcodes? Unequal objects have equal
hashcodes all the time.
Equality is defined in terms of the list of values you provide. This is
exactly like it's done in case classes and oh roughly everything.
// you define this
protected def hashValues: List[Any]
And then equals is defined as: hashValues == other.hashValues.
Also, that isn't Range, it's GenericRange.
--
Paul Phillips | It is hard to believe that a man is
In Theory | telling the truth when you know that you
Empiricist | would lie if you were in his place.
slap pi uphill! | -- H. L. Mencken
Hello Paul,
I'm sorry, it took a while for me to understand where I was off. I looked at the code in Hashable, saw the hashValues list, and then I saw how this list was compared in equalsHashValues. Somehow I came to the wrong conclusion it would just compare *hashCodes*. Of course it just compares the same *values* that are also used for calculating the hashCode.
Sorry for the noise.
Cheers,
Daniel
