Re: Style, Efficiency, and updating nested structure

Thanks for the replies, as always lots of interesting ways to do it in clojure. No zipper sugestions? For my own take, I happen to like the last suggestion (Gareth's) the most I think, of the ones offered so far. It has a lispy elegance and is still relatively efficient in traversals and memory

Re: Style, Efficiency, and updating nested structure

I would like to argue that your code has to be pretty inefficient if it's creating a bigger performance impact than fetching from the database. Erik. -- i farta > Den 12. nov. 2015 kl. 15.36 skrev Dave Tenny : > > Thanks for the replies, as always lots of interesting

Re: Style, Efficiency, and updating nested structure

Hey Daves I too like the map idea (and using sets for roles for that matter). But sticking with collections, I might do something like this (defn upsert "Updates or inserts v into coll" [key-fn update-fn v coll] (let [k(key-fn v)] (letfn [(step [v [x & xs]]

Re: Style, Efficiency, and updating nested structure

In general, it's not helpful to reach for optimisations like mutability without a benchmarking tool to tell you how much of a difference you're making. I'd be tempted to write something like: (defn find-project-index [projects id] (first (keep-indexed (fn [i p] (if (= (:project_id p) id)

Re: Style, Efficiency, and updating nested structure

I have been using Specter https://github.com/nathanmarz/specter recently with great success for doing all kinds of transformation: (let [project-id 10 new-role :r3 projects [{:project-id 1 :project-roles [:r1]} {:project-id 2 :project-roles [:r2]}]

Re: Style, Efficiency, and updating nested structure

I can't speak much to the efficiency analysis, but if I was solving the problem I would attempt to change the data structure. If the `proj-roles` could be a map then everything could be quick map updates. Given you run this in a loop to aggregate everything perhaps converting to that form before

Re: Style, Efficiency, and updating nested structure

Hi Dave, I would prefer functional approach (the latter, one without atoms and reset!) over the one with mutable local state. I would also refactor the update case as a separate function. Both are from the style perspective. I would try to optimize after I'm happy with how the code reads. And

Re: Style, Efficiency, and updating nested structure

- Worrying about the performance of a small, pure function like this is almost certainly premature optimization. - Avoid concurrency constructs like atoms if you don't need them. - Have you considered using group-by? > On Nov 11, 2015, at 13:25, Dave Tenny wrote: > > A