Hi Steve,
thank you for taking a look and for your suggestions!
> This part concerns me:
>
> > Note: Since clojure maps are no java maps, they can't be equal to java
> > maps. This holds for wrapped clojure maps as well - surprisingly (in a
> > bad sense), but i don't see a way around this:
>
> > (= (doto (HashMap.) (put 1 2)) {1 2})
> > -> false
>
> > (= (jmap {1 2}) {1 2})
> > -> false
That bugs me too, and i did try to resolve it. As far as i can see,
there are only two ways out, neither of which i like very much (worst
first):
1. Break the transitivity of = (for cases where you wouldn't expect it
to break)
2. Change = to (= a b) not necessarily being equivalent to a.equals(b)
re 1: Basically, (= a b) maps to a.equals(b) in Java (except for nil
and numbers). Suppose we'd like it to stay that way. Implementing =
for jmaps and Clojure maps would of course be easy and just a matter
of extending their equals-methods accordingly (we'd like = to be
symmetric, which means "mutual agreement" on equality in Java).
Suppose we had three representations of the same mapping: a Clojure
map a, a jmap-wrapped Clojure map b and a plain Java map c. Of course,
we want (= b c), that's the point of the whole undertaking. We also
have (= a b) after augmenting the equals-methods in question, but we
can't possibly have (= c a), because a Java map won't agree on being
equal to anything else but a Java map.
(I realise that, for arbitrary Java objects and funny implementations
of equals, = is anything but an equivalence relation, but here it
always breaks, even if equals is defined sensibly)
re 2: The idea would be to check whether we're comparing a mix of
Clojure maps and Java maps, if so, compare them entry-wise (along the
lines of the definition you gave), disregarding the Java maps
"equals". I think this would lead to weird equality semantics (e.g. a
Clojure map would appear = to a Java map within Clojure, but not from
the Java point of view, thus you couldn't pass it to Java methods that
expect Java maps).
Either way we turn it, it looks like the distinction between Clojure
maps and Java maps can only be blurred, but not removed in a
consistent way. The examples above are somewhat factitious, but
they'll likely lead to quite real issues that will be hard to
understand/explain/debug.
So i'd like to argue for a clean cut instead of blurring. In that
sense, jmap is just a function that returns a Java object, not a
Clojure map type. :-) I considered not supporting conj, assoc and
invoking on them to avoid creating that outward expression, but i went
for practicality here.
Kind regards,
achim
On Sep 29, 9:20 pm, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
> Hi achim,
>
> That looks like a fine start. Thanks for doing it!
>
> This part concerns me:
>
> > Note: Since clojure maps are no java maps, they can't be equal to java
> > maps. This holds for wrapped clojure maps as well - surprisingly (in a
> > bad sense), but i don't see a way around this:
>
> > (= (doto (HashMap.) (put 1 2)) {1 2})
> > -> false
>
> > (= (jmap {1 2}) {1 2})
> > -> false
>
> Here's my understanding of how = works in Clojure (corrections welcome):
>
> Clojure defines "=" (for all types) as "has the same value". For two
> maps A and B (of any concrete type) this means:
>
> For every key in A there exists a key in B that is = to it.
> For every key in B there exists a key in A that is = to it.
> For every key k in A, the value associated with k in A is = to the
> value associated with k in B
>
> The map types that we have now implement this. I think it's very
> important that jmap fit in with that definition of "=".
>
> What prevents jmap from participating in this same check? If there are
> more changes to existing Clojure code that are necessary to support
> this, I think they should be part of a jmap patch.
>
> --Steve
>
> On Sep 29, 2008, at 2:30 PM, Achim Passen wrote:
>
>
>
>
>
> > Hi!
>
> > Here's a patch to add java.util.Map support to clojure maps, along
> > with some example code. This my first java code in quite some time, so
> > if you notice i'm doing anything odd or incorrect, please don't
> > hesitate to comment.
>
> >http://groups.google.com/group/clojure/web/jmap.diff
> >http://groups.google.com/group/clojure/web/jmap-examples.clj
>
> > It has been discussed why clojure maps do not implement the
> > java.util.Map interface (short version: j.u.Map and j.u.Collection
> > clash, Collection being preferrable). This patch provides two
> > functions, "jmap" and "cmap", the former to wrap a clojure map in a
> > flyweight wrapper that provides the j.u.Map implementations, the
> > latter to unwrap it again.
>
> > The results of a calls to j.u.Map methods are automatically wrapped
> > again if they return maps, so from the java point of view, nested
> > clojure maps show up as nested java maps.
>
> > From the clojure point of view, wrapped maps retain most of the
> > functionality of their unwrapped counterparts: they can be invoked,
> > assoced and conjed, etc., the result being a full-featured clojure map
> > in each case. However ...
>
> > Note: Since clojure maps are no java maps, they can't be equal to java
> > maps. This holds for wrapped clojure maps as well - surprisingly (in a
> > bad sense), but i don't see a way around this:
>
> > (= (doto (HashMap.) (put 1 2)) {1 2})
> > -> false
>
> > (= (jmap {1 2}) {1 2})
> > -> false
>
> > Efficiency: lookup key- and mapentry-sets on wrapped maps should be
> > fast, since they just delegate calls to the clojure map inside. Lookup
> > on the values takes linear time though, and as far as i can see, we
> > can't do better, because the values themselves are not structured for
> > fast access in clojure maps.
>
> > Comments are most welcome!
>
> > Kind regards,
> > achim
>
> > --
> >http://rauschabstand.twoday.net
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
