On Sunday, May 11, 2014 6:33:25 PM UTC-5, Alex Miller wrote: > > On Sun, May 11, 2014 at 2:06 PM, Mikera <mike.r.an...@gmail.com<javascript:> > > wrote: > >> OK..... this thread is a bit worrying. If I understand correctly, it >> means that we've now got inconsistent hash and equals functions. I suspect >> this hasn't bitten many people yet simply because it is unusual to mix Java >> and Clojure collections as keys in the same structure, but it seems like a >> really nasty issue. >> > > Reports of real problems in real codebases would change my own opinion of > the severity of this issue. >
Here's the real problem I feared when thinking about what was new in Clojure 1.6, which led to the testing that led to this thread: One of our Clojure applications has two kinds of clients. (1) Legacy Java clients use a legacy remoting lib w/ generated, shared-across-client-and-server Java value types as messages. Where those have a collection, that's exposed as a java.util.List<AnotherValueType>. (2) Newer (Clojure) clients use a lighter-weight message format that's easily read into Clojure data structures. Clients interested in the same data need to be aggregated, and the commonality is contained in one java.util.List<AnotherValueType> from a message the legacy clients send. The old code used those as map keys. The new code for Clojure clients currently builds a vector of AnotherValueType and throws that into the same map, where, under Clojure 1.5.1, vectors and non-Clojure Lists can play nicely together. Under Clojure 1.6, they won't play nicely any more. This is an easy problem to work around by making the keys from the two client types more similar, either vectors on both sides or non-Clojure java.util.Lists on both sides. Luckily the change on our side is recent, and Clojure 1.6 is brand new, so this jumped out at me as something to test well before embarking on an upgrade, and this is a (probably) subtle bug we've avoided. What primarily worries me about the new behavior is that Clojure has always embraced the host platform, but the notion of "value" that seems to be reified in 1.6 excludes the closest things the Java platform has to collection values. While I agree a java.util.ArrayList is a bad value, mutability is not part of the java.util.List contract – it's optional – and even the best (immutable) Java collection value type one can write wouldn't be treated as a value by Clojure 1.6 unless it also implemented some clojure.lang interface(s) (which no sane Java lib would do). In the spirit of embracing the host platform, I'd like to see support for Java collections as values (and let those who mutate their value-treated Java collections deal with the nasty consequences). >From the comments on the ticket (http://dev.clojure.org/jira/browse/CLJ-1372), particularly Alex Miller's two longer comments from March 10th, I have the impression that there's no principled objection to this, just the performance concern with supporting so many types in hasheq. Does that seem right, Alex? I'd feel much better about an open issue and agreement that Clojure is in search of a high-performance implementation treating Java collections as values than about clear documentation of when and why hasheq is and will remain inconsistent w/ = and all the quirks that follow from that. (Though since we're living w/ the inconsistency, that documentation is important.) Thanks. -hume. -- 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.
