On 10 December 2013 18:24, larry google groups <lawrencecloj...@gmail.com>wrote:

>
> > As an aside, this doesn't look like a good use-case for macros
> >. You'd probably be better defining a map with keys for :
> > worker, :channel, etc. Either that or a protocol.
>
> Thank you much for your help. But I thought this is exactly what macros
> were for? In another language I would end up just copying-and-pasting the 4
> defs, and then changing "update" to "remove" so I could have both an update
> channel and a remove channel. I thought that macros were suppose to be good
> at removing that kind of redundancy?
>

Macros should be considered a "last resort" feature. They are usually the
worst way of solving a problem, unless they are the *only* way of solving a
problem.

Let's consider the functions your macros produce (ignoring the channel for
now):


(add-to-update-channel document)

(update-mongo-worker)

(start-mongo-channel)


These functions are very specific, but we can make them more
general-purpose by adding an additional argument:

(add-to-channel mongo-updates document)

(update-worker mongo-updates)

(start-channel mongo-updates)


Since these are generic functions, any specific functionality must be
defined by the new "mongo-updates" argument. In your example there are two
things specific to the mongo update job: the channel, and the function to
execute.

We could place these two piece of information in a data structure:

(def mongo-updates

  {:channel (channel)

   :to-execute println})


Or we could define a type or protocol. For now the map seems good enough,
and we can use it to build generic versions of the functions generated by
your macro:

(defn add-to-channel [{:keys [channel]} data]
  (enqueue channel document))

(defn update-worker [{:keys [channel to-execute]}]
  (loop [document @(read-channel channel)]
    (to-execute document)
    (recur @(read-channel channel))))

(defn start-channel [worker-info]

  (dotimes [_ 6]

    (future (update-worker worker-info))))


- James

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to