Mark, any thoughts on what you planned to do for data.priority-map?
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/groups/opt_out.
I am glad you have documented how other collections should implement hasheq going forward from Clojure 1.6, but that doesn't address the question of what a collection library ought to do if it wants to continue to support Clojure 1.5.1 as well as the 1.6 and later.
In fact, it calls the Java method mapHasheq, which still exists in Clojure's Java code, but still implements the old hash calculation. Is it planned to deprecate that method? Update it? Something else?data.avl is probably a better example -- it currently implements hasheq on its collections in its own code.data.priority-map was a bad example, as Mark pointed out it simply passes on the hash calculation to an existing Clojure collection, so it is coming along 'for free' with the hash change.
I was planning on using a macro to check (Class/forName
"clojure.lang.Murmur3") or *clojure-version* in both core.rrb-vector
and data.avl. Clojure already uses this approach (checking
Class/forName) to compile against the appropriate ForkJoin
implementation in clojure.core.reducers.
As long as the new hashing
API remains stable, this should be a straightforward way to make an
external impl's hashing strategy future-proof. And if things change
again, we'll just use the same trick. (Andy has just provided a patch
to data.avl using the *clojure-version* approach -- thanks!)
Incidentally, I wish the basic methods -- hashOrdered, hashUnordered
-- were exported by a class with a generic name, perhaps HashEq or
HashUtils, just so that they wouldn't need to change if the algorithm
gets swapped out for another one at some point. Introducing Clojure
functions for hashing would work too, I suppose, although I think I'd
actually prefer static methods, at least until Clojure's interfaces /
protocols are unified across platforms.
As for doing nothing: not sure if that refers to Clojure itself or to
The parts you should consider standard and public are exactly the parts documented at http://clojure.org/data_structures#hash. Namely, that unordered collections sum the hasheq of their elements and that ordered collections use the 31* + algorithm and that both finish with a call to mix-collection-hash. The algorithm for mix-collection-hash is subject to change.
an option would be to provide an :inline implementation to avoid all casting/boxing