The concept of a lazy-map might sounds odd at first. How do you know if a map
contains an entry without resolving the whole map? But it’s not the entries that
are lazy, it’s the values they hold. See this example from the Readme:
Lazy-map is on Clojars, so you can just add it as a dep and play around:
How would this ever be useful?
One of my side projects a few months ago (when I was playing around with
Clojure-on-Android) was an Android client for a desktop Java application.
Because of this, a lot of the code was about interfacing with Java objects
defined by this package. These objects were from many different classes, but
the one thing they had in common is that they were full of get methods.
I wanted so much to be able to use these objects as maps that I wrote a protocol
for converting general objects to Clojure maps. Here’s an example of how it
worked on a string.
user>(to-map"My own String!"){:to-char-array#object["[C"0xdf4ddb3"[C@df4ddb3"],:empty?false,:to-string"My own String!",:chars#object[java.util.stream.IntPipeline$Head0xad35343"java.util.stream.IntPipeline$Head@ad35343"],:classjava.lang.String,:length14,:trim"My own String!",:bytes#object["[B"0x75ef7d8f"[B@75ef7d8f"],:hash-code1673659170,:object"My own String!",:to-upper-case"MY OWN STRING!"}
For comparison, here’s how bean works (a similar function from
clojure.core).
user>(bean"My own String!"){:bytes#object["[B"0x1ad60072"[B@1ad60072"],:classjava.lang.String,:emptyfalse}
The protocol is actually quite smart. It uses a number of heuristics to only
convert methods that look like they’re side-effect free. Of course, it’s not
foolproof (this is Java we’re talking about), but the macro used to extend the
protocol lets you specify methods to exclude.
The only problem was the performance cost. Some of these methods were very
expensive to run, and eagerly calling all methods of all objects just so I could
later access some of these was obviously a bad deal. The solution, clearly, was
to only call these methods when the map entries were actually accessed. And so
lazy-map was born.
New Clojure lib: lazy-map
15 Nov 2015, by Artur Malabarba.The concept of a lazy-map might sounds odd at first. How do you know if a map contains an entry without resolving the whole map? But it’s not the entries that are lazy, it’s the values they hold. See this example from the Readme:
Lazy-map is on Clojars, so you can just add it as a dep and play around:
How would this ever be useful?
One of my side projects a few months ago (when I was playing around with Clojure-on-Android) was an Android client for a desktop Java application. Because of this, a lot of the code was about interfacing with Java objects defined by this package. These objects were from many different classes, but the one thing they had in common is that they were full of
getmethods.I wanted so much to be able to use these objects as maps that I wrote a protocol for converting general objects to Clojure maps. Here’s an example of how it worked on a string.
For comparison, here’s how
beanworks (a similar function fromclojure.core).The protocol is actually quite smart. It uses a number of heuristics to only convert methods that look like they’re side-effect free. Of course, it’s not foolproof (this is Java we’re talking about), but the macro used to extend the protocol lets you specify methods to exclude.
The only problem was the performance cost. Some of these methods were very expensive to run, and eagerly calling all methods of all objects just so I could later access some of these was obviously a bad deal. The solution, clearly, was to only call these methods when the map entries were actually accessed. And so
lazy-mapwas born.Tags: clojure, emacs,
Test-Driven-Development in CIDER and Emacs »
« Using prettify-symbols in Clojure and Elisp without breaking indentation
Related Posts
A small improvement to clj-refactor in clojure
Conditional breakpoints in the CIDER Debugger in clojure
Update on tdd-mode with CIDER in clojure
Content © 2019, All rights reserved. Icons under CC3.0.