Hi, Am 26.06.2009 um 23:44 schrieb Michael Spiegel:
Running the following test code generates an exception: =>(def foo (sorted-set "bob" "alice" "michael")) => (contains? foo 5)java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Number (NO_SOURCE_FILE:0)I've tracked down the source of the exception to the method clojure.lang.Util.compare. This method will test whether the first argument is a number (which it is), and then perform Numbers.compare() on the two arguments. However the set contains strings, so when ops() is invoked on the second argument, the default value for an ops is INTEGER_OPS, which then barfs when the string is treated as an IntegerOps type. I don't know what is the policy of allowing users to shoot themselves in the foot. IMO Util.compare should not assume the second argument is a number when the first argument is a number. But I thought I would point out this behavior and elicit comments from the group.
IIRC, this came up already. And the general result was, that it is a bug in the user code to compare an Integer with a String. A sorted-set is not a usual set. It contains elements, which can be sorted according to an ordering. Comparing two things, where one is not in the domain of the ordering, is not defined. So when I have a sorted-set, I also have a special kind of elements, ie. the domain of the ordering. If I try to use something outside the domain with my set, it is most likely a bug. IMHO, it is correct, that an exception is thrown in that case. Sincerely Meikel
smime.p7s
Description: S/MIME cryptographic signature
