On Mar 30, 2009, at 12:36, Mark Engelberg wrote:
> I'm aware that a and 123 have different types, but I was under the
> impression that the hash set implementation was supposed to just rely
> on hash codes and equality. Why does the type come into play, and is
> this really the desired behavior?
It looks like a bug to me, for the reasons you mention.
BTW, hash sets are implemented in terms of hash maps, which show the
same behaviour:
(def a (BigInteger. "123"))
({a :found} 123)
returns nil.
Looking at the implementation of PersistentHashMap, I note that the
ultimate key equality test is (line 560):
public LeafNode find(int hash, Object key){
if(hash == this.hash && Util.equals(key, this.key))
return this;
return null;
}
The test applied is Util.equals, so let's try that:
(. clojure.lang.Util equals a 123)
This returns false, unlike
(. clojure.lang.Util equiv a 123)
which returns true. clojure.core/= calls equiv, which is why (= a
123) is true. equiv is the same as equals EXCEPT for numbers and
Clojure collections, so perhaps sets and maps also have some surprise
behaviour for collections.
I don't know if there is a good reason for using equals rather than
equiv in testing for key equality in maps. Using equiv would better
agree with my expectations.
Konrad.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
