dj.dispatch.treefn — org.bmillare/dj.treefn 0.2.0

(let [args {:x 1, :y 2} fms {:add (fm [:x :y] (+ x y))} tf (treefm fms :add)] (tf args))

dependencies->rev-edges clj

(dependencies->rev-edges direct-dependency-map)

converts dependency graph into a graphviz friendly edge vector representing flow of data

dismantlefm clj

(dismantlefm dismantle-map tree-fn)

dismantle map should include functions (fms) that dismantle the object passed in, also for bookkeeping, any entries in the map may also be used to determine what will be removed from the map after dismantling (handled externally).

If value-specific dismantle function is not provided, will also call type specific Idismantle

On dismantle exception, immediately gives up, this is a tradeoff in that you can try to manually handle the case, extract debugging information, and then if so choose, continue the dismantle process by reinvoking with remaining objects

dismantle-if, the returned fn, when called returns nil

Might want to match the semantics of Stuart Sierra's component, where construction or destruction returns the data again

fm clj macro

(fm bindings & body)

adds dependency metadata to fn, uses map destructuring assume you provide the vector in {:keys [a b ...]}

graphviz-data clj

(graphviz-data treefn)

Idismantle clj protocol

dismantle clj

(dismantle this)

destroy or close resource

invalidate-entries clj

(invalidate-entries val-map treefn touched-nodes)

removes keys/vals of val-map that have been children of the recursively touched

touched-children clj

(touched-children tree-fn touched-nodes)

treefm clj

(treefm fn-map root-key)

shakes fm-map with root-key and produces a treefn but with fm instead of fn, which uses map destructuring

Internally, maps are being passed around to the functions

treefm-print-debug clj

(treefm-print-debug fn-map root-key)

shakes fm-map with root-key and produces a treefn but with fm instead of fn, which uses map destructuring

Internally, maps are being passed around to the functions