On Mon, Jan 31, 2011 at 11:33 PM, Jason Wolfe <[email protected]> wrote:
> I just ran into the following surprise:
>
> user> (defrecord P [])
> user.P
> user> (defrecord Q [])
> user.Q
> user> (= (P.) (Q.))
> false
> user> (.equals (P.) (Q.))
> true
>
> This is not a bug (but I do find it confusing -- I did not expect (P.)
> and (Q.) to collide as map keys):
> http://groups.google.com/group/clojure/browse_frm/thread/7ba5215d59f2f177
>
> However, the docstring of defrecord says it "will define type-and-
> value-based equality and hashCode". Perhaps this could be
> clarified?
It seems clear enough to me that type is a factor in equality.
The real bug here is that .equals returns true in this case.
> Along the same lines, the docstring of = says "same as Java
> x.equals(y), 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.
There is where clarification is needed, namely that records are not
"collections" for this purpose.
Alternatively, records could have an enforced mapping {:type
TheRecordsClass} that does not actually take up storage space, but
appears when records are queried and automatically imposes the desired
equality semantics if records were simply treated as maps -- other
than that a plain map with the same type key-value pair could now
compare equal to the record. (Would that be a bad thing though?)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
