http://dev.clojure.org/jira This file is an XML representation of an issue en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/CLJ-736 Clojure <p><a href="http://groups.google.com/group/clojure/browse_frm/thread/eba691b38c45196b#">http://groups.google.com/group/clojure/browse_frm/thread/eba691b38c45196b#</a></p> <p>The docstring of defrecord says it "will define type-and- <br/> value-based equality and hashCode". In reality, record types are included in = but not .equals (or hashCode), and so records of different types can collide as map keys. </p> <p>Along the same lines, the docstring of = says "same as Java x.equals<img class="emoticon" src="http://dev.clojure.org/jira/images/icons/emoticons/thumbs_up.gif" height="19" width="19" align="absmiddle" alt="" border="0"/>, except it ... compares numbers and collections in a type-independent manner". To me, this seems to imply the opposite of what actually happens with records. </p> <p>FWIW I think it would be more clear if the behavior for = and .equals were the same in this respect, but in any case the implemented behavior should be properly documented.</p> CLJ-736

Docstring of defrecord (and =) does not correctly describe equality behavior for records.

Enhancement Minor Closed Completed Stuart Halloway Jason Wolfe Wed, 9 Feb 2011 18:00:40 -0600 Fri, 1 Mar 2013 12:47:03 -0600 Fri, 2 Sep 2011 09:39:50 -0500 Release 1.2 Release 1.3 Release 1.4 Release 1.3 Release 1.4 0 2 <p>Also discussed at <a href="https://groups.google.com/d/topic/clojure/e6UhXVny8Xc/discussion">https://groups.google.com/d/topic/clojure/e6UhXVny8Xc/discussion</a></p> <p>Per Rich, "The policy is: = includes the type and .equals doesn't. In this way records can still be proper j.u.Maps and = remains most useful for records (e.g. including type)."</p> <p>On a related note:</p> <p><a href="http://dev.clojure.org/display/doc/Enhanced+Primitive+Support?focusedCommentId=1573146#comment-1573146">http://dev.clojure.org/display/doc/Enhanced+Primitive+Support?focusedCommentId=1573146#comment-1573146</a></p> <p>Regarding "hash maps and sets now use = for keys ... will use stricter .equals when calling through java.util interfaces":</p> <p>Note that "=" is actually stricter than ".equals" for record types currently, because it includes type information.</p> <p>This has important consequences for how (and whether) hash maps and sets actually obey the java.util interfaces.</p> <p>For instance, if </p> <p>(defrecord P []), ...</p> <p>what should (.get {(P.) 1 (Q.) 2} (Q.)) return? How about if we .get an element of a third type (R.)?<br/> <br/> In a similar vein, this behavior seems confusing at best:<br/> <br/> user=&gt; (java.util.HashMap. {(P.) 1 (Q.) 2})<br/> #&lt;HashMap {user.P@0=2}&gt;</p> <p>Open question:</p> <ul> <li>the phrase "type-independent" is confusing. It is intended to talk about concrete numeric and collection types, but I can see why it gets confusing with records. Need an idea for two different terms here (and define them someplace). If somebody has one, please add it to this ticket.</li> </ul> <p>Non-issues:</p> <ul> <li>= and .equals are not and will not be the same. The whole point is to avoid Java's broken semantics (=) while providing an interop formula for those who need it (.equals)</li> <li>Any types can collide as hash keys.</li> </ul> <p>Any thoughts on the open questions part Rich?</p> <p>I think the following is better:</p> <p><tt>monospaced</tt><br/> In addition, defrecord will define type-and-value-based =,<br/> and will defined Java .hashCode and .equals consistent with the<br/> contract for java.util.Map.<br/> <tt>monospaced</tt></p> <p>But I don't want to hold release for discussion, so bumping this to approved backlog for further bikeshedding. <img class="emoticon" src="http://dev.clojure.org/jira/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></p> <p>Better yet, let's just agreed on my prose and call this done.</p> Approval Accepted Global Rank Waiting On stu