Clojurians Log v2

@seancorfield why not just have your custom map type normalize the keys coming in, and implement equiv so it considers itself equal to a plain Clojure map that would otherwise be the same if its keys were normalized? I implemented a lisp-case/`snake_case` insensitive map a while back for a project I'm working on and that's finally the behavior I settled on. This way I don't have to update any old tests and things like select-keys still mostly do the right thing

@camsaul As I said: this is “for non-Clojure language interop reasons”. It has to work as a hash map in the non-Clojure code too and that requires access via UPPERCASE STRINGS.

Maybe you could make the key behavior switchable and do something like (uppercase-keys-map my-map) in the Java interop code? Not an ideal solution but not sure one really exists

Aside from select-keys pulling the rug out from under me, what we’ve got works great, and has done for years as we slowly rewrite all that legacy code in Clojure 🙂

So, eventually, I won’t have to care about this funky hash map type!

It took me quite a while to arrive at a data structure that would round-trip between the legacy host language and the embedded Clojure code (invoked via the Java API). select-keys is the only thing that trips me up from time-to-time. Everything else “just works” so it looks like a case insensitive hash map to the host language (uppercase string keys) and like a regular Clojure map with keyword keys and almost every operation in both languages preserves the illusion.

The host language is ColdFusion/CFML (running on the JVM) in case you’re wondering… 🙂

Maybe a bad idea, but why not just intern a version of select-keys that fixes the bug? Not something you should do all time but I think in exceptional circumstances you might want to do something like that

That is slightly tempting (but probably a bad idea 🙂 ).