The semantics of a set doesn't guarantee an order either (even though it's implementation might), I'd sort over the keys and use the resulting collection as hash-map key so you are independent of any clojure-intrinsic behavior.
On Thursday, July 2, 2015 at 3:06:00 AM UTC+2, Fluid Dynamics wrote: > > On Wednesday, July 1, 2015 at 3:54:03 PM UTC-4, Jo Geraerts wrote: >> >> Hey, >> >> I when i tried to run my program with the shiny new 1.7, it broke. I have >> traced it down to the fact that zipmap ( >> https://github.com/clojure/clojure/blame/master/src/clj/clojure/core.clj#L2940) >> >> does returns the keys in a different order than i'm used to. >> >> e.g clojure 1.6: >> >> nREPL server started on port 52315 on host 127.0.0.1 - nrepl:// >> 127.0.0.1:52315 >> REPL-y 0.3.5, nREPL 0.2.7 >> Clojure 1.6.0 >> Java HotSpot(TM) 64-Bit Server VM 1.8.0_40-b26 >> Docs: (doc function-name-here) >> (find-doc "part-of-name-here") >> Source: (source function-name-here) >> Javadoc: (javadoc java-object-or-class-here) >> Exit: Control+D or (exit) or (quit) >> Results: Stored in vars *1, *2, *3, an exception in *e >> >> user=> (zipmap [:a :b] [:c :d]) >> {:b :d, :a :c} >> >> Whereas clojure 1.7 does: >> >> nREPL server started on port 52193 on host 127.0.0.1 - nrepl:// >> 127.0.0.1:52193 >> REPL-y 0.3.5, nREPL 0.2.7 >> Clojure 1.7.0 >> Java HotSpot(TM) 64-Bit Server VM 1.8.0_40-b26 >> Docs: (doc function-name-here) >> (find-doc "part-of-name-here") >> Source: (source function-name-here) >> Javadoc: (javadoc java-object-or-class-here) >> Exit: Control+D or (exit) or (quit) >> Results: Stored in vars *1, *2, *3, an exception in *e >> >> user=> (zipmap [:a :b] [:c :d]) >> {:a :c, :b :d} >> >> As i'm using the keys function later on these values as a multimethod >> dispatch function, things break. >> >> It's rather trivial to change my program with the new ordering, but i was >> wondering if the ordering of the keys of the returned map is part of the >> contract. >> >> When one would need more context about the actual code, the usage of the >> zipmap can be found here at >> https://github.com/jgeraerts/imageresizer/blob/master/src/net/umask/imageresizer/urlparser.clj#L19 >> . >> The multimethod dispatch >> https://github.com/jgeraerts/imageresizer/blob/master/src/net/umask/imageresizer/resizer.clj#L15 >> >> The tests break with these kinds of exceptions: >> >> ERROR in (test-resizer) (MultiFn.java:156) >> expected: (= [200 [200 200]] (run-resizer "size/200x200/rose-cmyk.tiff")) >> 20:31:05.179 [main] WARN net.umask.imageresizer.resizer - image not >> found for uri size/200x200/nonexisting >> actual: java.lang.IllegalArgumentException: No method in multimethod >> 'scale' for dispatch value: (:width :height) >> at clojure.lang.MultiFn.getFn (MultiFn.java:156) >> clojure.lang.MultiFn.invoke (MultiFn.java:233) >> >> I'm glad to hear your feedback. >> > > Key order for (non-sorted) maps is not guaranteed, but there is an easy > fix: pour the result of keys into a set, e.g. (into #{} (keys my-map)), and > use #{:width :height} e.g. as your dispatch values. Then it will work > independently of the vagaries of key ordering. > -- 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 Note that posts from new members are moderated - please be patient with your first post. 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
