Clojurians Log v2

@dominicm can you give an example?

@yonatanel Sure! Say you have an event processing component, in a system of components with varying connections and so on. The events component reads from a channel, and calls the multimethod process-event! on the event. Whereever you add a new process-event! which talks to a new component in any way, you have to go and add a new dependency to the events component. The events component has to know of every method which extends process-event! and include all of those dependencies. One option I can see is to just hand over the entire system: at any given time, the process-event! function will need to access parts of it. Overall, this scenario feels like it's missing a lot of the code locality I've come to love from the component pattern. mount works in this scenario though! As the extensions to process-event! would just refer to the namespace of the state that they want.

I think mount is the easy way out. I don't like the mount way

Me neither. In terms of trade offs, I don't think this one edge case would pull me away from component.

@dominicm You can defmulti and defmethod on separate namespaces. Maybe that's a hint

@yonatanel But how would you defmethod in a way that it could specify the state it needs as it's own dependencies?

I don't know how you'd implement that, but i think process-event! parameters should only be the event and context, and get the rest from lexical scope e.g implemented inside a defrecord, perhaps even in one of your components.

i wonder if you can defmethod inside a component. Either way, you may need a full fledged "router" of events to event-processors, or have each processor register to the stream of events and take only what it can handle.

https://groups.google.com/forum/#!topic/clojure/Xp40xv2AJpI

@dominicm take a look at https://github.com/metosin/kekkonen. Seems interesting. I am now reading it to see how they dispatch