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 ways to do it in
> cloj
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
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]]
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) i)
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]}]
^IPersistentVect
- 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 colleague and I are deb
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
d
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 h
A colleague and I are debating various things clojure as we were exploring
alternative ways to solve a problem.
Here's the description of the problem that a particular function is trying
to solve, and the first implementation of it.
(defn update-roles
"Given a vector of maps of the form {:pr
On Aug 28, 11:43 am, Parth Malwankar <[EMAIL PROTECTED]>
wrote:
> On Aug 28, 8:08 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Aug 27, 10:37 pm, Parth Malwankar <[EMAIL PROTECTED]>
> > wrote:
>
> > > On Aug 28, 12:10 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > > > I posted a vari
On Aug 28, 8:08 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Aug 27, 10:37 pm, Parth Malwankar <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > On Aug 28, 12:10 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > > I posted a variant here:
>
> > >http://paste.lisp.org/display/65964
>
> > Rich,
>
> > It wo
On Aug 27, 10:37 pm, Parth Malwankar <[EMAIL PROTECTED]>
wrote:
> On Aug 28, 12:10 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > I posted a variant here:
>
> >http://paste.lisp.org/display/65964
>
> Rich,
>
> It works very nicely. Thanks.
>
> Just one thought in case the functions args are st
On Thu, Aug 28, 2008 at 2:01 AM, Parth Malwankar
<[EMAIL PROTECTED]> wrote:
>
> On Aug 28, 8:13 am, Chouser <[EMAIL PROTECTED]> wrote:
>>
>> (apply mk-get my-fridge (item-path :mango) :quantity)
>
> I get an error with this.
>
> user=> (item-path :mango)
> [:fruits :mango]
> user=> (apply mk-get m
On Aug 28, 8:13 am, Chouser <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 27, 2008 at 10:37 PM, Parth Malwankar
>
> <[EMAIL PROTECTED]> wrote:
> > In case the access path were vectors the above could become:
>
> > (mk-get my-fridge (item-path :mango) :quantity)
> > (mk-assoc my-fridge (item-path :man
On Wed, Aug 27, 2008 at 10:37 PM, Parth Malwankar
<[EMAIL PROTECTED]> wrote:
> In case the access path were vectors the above could become:
>
> (mk-get my-fridge (item-path :mango) :quantity)
> (mk-assoc my-fridge (item-path :mango) :quantity new-quantity)
>
> Much less noise.
apply actually can
On Aug 28, 12:10 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> I posted a variant here:
>
> http://paste.lisp.org/display/65964
>
Rich,
It works very nicely. Thanks.
Just one thought in case the functions args are still being
decided on. Could we consider taking access path as a
vector rather
On Aug 27, 4:39 am, Parth Malwankar <[EMAIL PROTECTED]> wrote:
> On Aug 26, 8:25 pm, Parth Malwankar <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hello,
>
> > In order to update fields in nested structures/maps easily
> > I have created a macro 'field-write'.
> > (defmacro field-write [st k v access
On Tue, Aug 26, 2008 at 11:25 AM, Parth Malwankar
<[EMAIL PROTECTED]> wrote:
>
> In order to update fields in nested structures/maps easily
> I have created a macro 'field-write'.
It looks like this has come up on IRC a few weeks ago:
http://clojure-log.n01se.net/date/2008-07-15.html#09:22
I had
On Wed, Aug 27, 2008 at 4:39 AM, Parth Malwankar
<[EMAIL PROTECTED]> wrote:
> After some more experimentation I found that the field-write
> macro didn't work with access-specs like (vector :a :b :c)
> ... I should have thought of that before.
>
> So I reimplemented field-read and field-write as f
On Aug 26, 8:25 pm, Parth Malwankar <[EMAIL PROTECTED]> wrote:
> Hello,
>
> In order to update fields in nested structures/maps easily
> I have created a macro 'field-write'.
> (defmacro field-write [st k v access-spec]
> ; st=data, k=key to update, v=val to put, access-spec=access
> v
Hello,
In order to update fields in nested structures/maps easily
I have created a macro 'field-write'.
(defmacro field-write [st k v access-spec]
; st=data, k=key to update, v=val to put, access-spec=access
vector
; ... code listing after interaction
user=> nx
{:a {:b {:
21 matches
Mail list logo
