On Mon, May 12, 2014 at 4:26 PM, John D. Hume <duelin.mark...@gmail.com>wrote:
> On Mon, May 12, 2014 at 12:53 PM, Alex Miller <a...@puredanger.com> wrote: > >> My recommendation in Java would be the same - using mutable objects as >> keys in a map (where mutability changes the hashcode) is a bug waiting to >> happen. >> > > Although I used java.util.ArrayList in the sample REPL session showing the > surprising behavior, I never said anything about the Java types used in our > application being mutable. That gets at my point: the "best" Java > collection values, the only ones that make good hashmap keys, are > immutable, but Clojure still gives them this mixed status where they're > equiv but not hasheq to IPersistentCollections w/ the same contents. > > [Having made that point again, I'll now admit that under the cover of > java.util.List<V>, the lists in messages our app receives are ArrayLists > :-), BUT they're never mutated, and we'd have the same issue if they were > Guava ImmutableList<V>, which is a fine value type (so long as V is > immutable).] > If you don't know, then you don't know... But, point taken. > In general, Clojure treats Java collections (and arrays) as values now >> ... but if you do mutation, then any Clojure guarantees are off (in >> hashing, in STM, etc). I think that's been generally a happy compromise so >> far. The question is to what extent that should continue. >> > > I'm totally happy to see crazy things happen to anyone who treats a > mutable collection as a value and then mutates it. > > It may even be that this could be supported without much of a hit. >> Strings, numbers, keywords, symbols, and all Clojure collections should be >> handled above the suggested change and that covers most common key types. >> Some research would need to be done on what common non-Clojure classes >> (hence not IHashEq implementors) fall into the final else case - >> java.lang.Class is one that comes to mind which is used a lot inside >> Clojure itself. >> > > I like the sound of this. One of your comments on the ticket mentioned JVM > inlining issues, which scared me. > Yes, me too. :) Needs investigation, which is why we did not try to jam it into 1.6. Is it a safe bet that protocol dispatch would be too slow for hasheq? > No clue - needs more investigation. > -- > 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+unsubscr...@googlegroups.com. > To post to this group, send email to clojure-...@googlegroups.com. > Visit this group at http://groups.google.com/group/clojure-dev. > For more options, visit https://groups.google.com/d/optout. > -- 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.
