Hi Russell, Maybe the concrete case will help. I have a single entry point into which Commands can be posted, let's call it a CommandGateway. This gateway will do many things, the least of which will be to delegate the handling of the command to the command handler registered with the gateway. The strategy is 'how to handle a command'.
Now, the handler for :command-a needs a database for example. The handler for :command-b needs another collaborator. CommandGateway has no idea about this and defines a defmulti called handle-command which dispatches on the :type of the command (which is really a trivial map). The command handler for :command-a registers a defmethod for :command-a but how does the body of that defmethod access the database connection for example? I can see a few options: - give up on avoiding global state and have a bound 'system' register (i.e. a global/static service locator) - please no. - don't use multi-methods for this and have CommandGateway have a map of predicate:handler. The handler for command-a would then register itself and use lexical scoping to access the required collaborators - use multi-methods, but have a CommandAHandler which is a stateful record and retains its collaborators (i.e. the database) and extends itself to implement command-handler) My question is really 'when does using types stop being idiomatic'. So far I have gotten surprisingly far using maps/sequences and passing collaborators around. Now it seems to use multi methods to dispatch the command I need the target of the dispatch to be stateful to remember its collaborators. Might all be a storm in a teacup :), hence the clarity request. On 12 August 2013 16:50, Russell Mull <russell.m...@gmail.com> wrote: > Generally, I'd go for a simple strategy (ahem) like this: > > (defn make-handler [wibblie wooblie] > (fn [woosy] > <eloquent code here>)) > > But perhaps there's something about your case that I don't understand; I'm > not entirely sure where multimethods need to come into it, unless you need > to change which handler you're using based on the thing it's handling. > > Russell > > -- > -- > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/hRKZTclcllQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- 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.
