Florian
--
Florian Ebeling
florian...@gmail.com
http://richhickey.github.com/clojure-contrib/fnmap-api.html
HTH,
--
Laurent
2010/1/18 C. Florian Ebeling <florian...@gmail.com>:
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
Do you want real case-insensitivity (i.e., you preserve the case of
some item in the map), or just down-casing?
To do that you need to alter the hashing and equality functions of the
map.
I have a Java implementation of a DowncaseMap which downcases String
keys (and thus avoids specifying the hash function), but obviously the
output is lowercase. I'm happy to share.
Yes, good point. I think the reasonable thing to do is downcasing for
my application.
> I have a Java implementation of a DowncaseMap which downcases String keys
> (and thus avoids specifying the hash function), but obviously the output is
> lowercase. I'm happy to share.
Thanks for the offer :) But I don't really want to resort to Java. I
was hoping for something transparant, but I realize now the
implications.
Not wanting to interrupt this thread, but this is amazing! I could
have used this a dozen of times in the past few months. Thanks for
pointing this out!
I haven't looked at how hard this would be to implement in Clojure; it
would be nice if there was those features (let me specify how to hash
keys, let me specify how to compare keys).
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
PersistentHashMap calls Util.hash(key), which calls key.hashCode().
You could use fnmap to replace input Strings with a
CaseInsensitiveString implementation that does hashing and comparison
case-insensitively...
Otherwise you'd probably need to subclass PHM and reimplement any
method that calls Util.hash.
This is actually a very cool approach and it fits my ideas quite well.
The only problem I have with it is that it constructs a whole new map
from keyvals. That sounds a bit expensive. Maybe it is possible do
something similar which just wraps over an existing map. I see if I
can come up with something like that. I understand that this doesn't
guarantee my the consistency within the map as I get it from having
all insertions done through the same setter. But in a case where one
just wants some transformation relying on the getter, that doesn't
matter.
Anyway, thanks for the pointer to this lib!
--
Florian Ebeling
florian...@gmail.com
On Jan 21, 11:01 am, "C. Florian Ebeling" <florian.ebel...@gmail.com>
wrote:
> This is actually a very cool approach and it fits my ideas quite well.
> The only problem I have with it is that it constructs a whole new map
> from keyvals. Maybe it is possible do something similar which just wraps
> over an existing map.
I think you misread the source of fnmap. Of course it creates a new
map in the beginning just as hash-map does. Then assoc/dissoc/etc.
just delegates to the underlying map with the appropriate fiddling
with the setter/getter.
If you already have a map you can do something like:
(require '[clojure.contrib.fnmap.PersistentMap :as fnmap])
(defn to-fnmap
[the-map setter getter]
(clojure.contrib.fnmap.PersistentFnMap. (assoc the-map ::fnmap/
setter setter ::fnamp/getter getter)))
> That sounds a bit expensive.
Did you try? "sounds" is not the best advisor.
Sincerely
Meikel
I didn't read the code as thoroughly as you did. Thanks for pointing
out this approach. It would make a nice addition to the exposed API.
--
Florian Ebeling
florian...@gmail.com