Repository navigation
Nested collection comparison #383
Description
(compare [1] [2]) ;; -1 is ok because vecotors are Comparable.
(compare '(1) '(2)) ;; BOOM throws an exception because lists are not Comparable, it's expected.
(compare ['(1)] ['(2)]) ;; BOOM it is also expected.
(db/value-compare [1] [2]) ;; -1
(db/value-compare '(1) '(2)) ;; -22.. it works because lists are compared by hash
(db/value-compare ['(1)] ['(2)]) ;; BOOM This case is too strange, I can compare vectors and lists but I can't compare vectors of lists.
I can wrap my vectors in a hash-map or a list and it works: (db/value-compare {:value ['(1)]} {:value ['(2)]}). But it's a hack.
Should we provide our own Compare protocol with hash support? In this case, we have to repeat a .compareTo method for all collections. It looks like .compareTo but calls our value-compare instead of Util/compare https://github.com/clojure/clojure/blob/c1ede7899d8d7dd4dcd6072d5c0f072b9b2be391/src/jvm/clojure/lang/APersistentVector.java#L439
This issue has a low priority.
Activity
tonsky commentedon Jan 19, 2021
Total compare function is great, but re-implementing it for every Clojure and Java type might be too much? On the other hand, maybe there’s not much work, in that case we can go for this.
tonsky commentedon Jan 19, 2021
Another solution might come from the user, who might decide not to store vectors of arbitrary types?
darkleaf commentedon Jan 19, 2021
And one more question. How do you think about comparing objects by their hash?
Two different objects can have equal hashes. It just works because we haven't a better solution, doesn't it?
tonsky commentedon Jan 19, 2021
Yes. Maybe identityHashCode would be better, if it’s based on object pointers addresses (needs checking)?