Rather than having hidden mutable state for wiring events to handlers, would it be clearer if the main namespace just passed an :event->[handlers] map to the event processor?
If that would create a huge, frequently changing data structure, each namespace with handlers could expose an :event->[handlers] map of its own, and the main ns could merge-with concat. That would at least make explicit what's currently implied by the main ns requiring all the handler namespaces. On Mon, Nov 18, 2013 at 4:07 PM, dm3 <deadmo...@gmail.com> wrote: > Hello, > > Looking for opinions :) > > I'm currently building an event-driven service which consumes events using > handlers. Now, the idea is to define a set of handlers (functions of type > Event->Unit) in different parts of the service, which are then invoked > when an event comes into the system. The dependencies are in the following > order: > > [ns.event-processor] -> [ns.handlers] <- [ns.handler-1], [ns.handler-2] > > Definition of a handler in *ns.handler-1* looks like this: > > (ns.handlers/defhandler Handler1 > (on :EventA [event] (do something)) > (on :EventB [event] (do something else))) > > The *defhandler* macro registers the handler in an atom, which is then > queried when the *ns.event-processor* receives an event. > You might have already figured out that I run into problems when the event > processor is invoked and not all of the handler namespaces have been loaded > yet. > Currently I resolve this by explicitly requiring all of the namespaces > which invoke *defhandler* from the main application namespace which > constructs the running system. > > It seems that I'm looking for some cross-ns var discovery mechanism, > something like classpath scanning in Java (which smells like an > anti-pattern in Clojure). > I was wandering whether I'm missing some cleaner/better approach? > > Thanks, > Vadim > > -- > -- > 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. > -- http://elhumidor.blogspot.com/ -- -- 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.
