architecture

2016-09-04T09:04:19.000003Z

@dominicm can you give an example?

dominicm 2016-09-04T09:27:08.000004Z

@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.

2016-09-04T09:30:04.000005Z

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

dominicm 2016-09-04T09:30:47.000006Z

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

2016-09-04T09:35:12.000007Z

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

dominicm 2016-09-04T09:36:36.000008Z

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

2016-09-04T09:43:13.000009Z

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.

2016-09-04T09:45:26.000010Z

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.

2016-09-04T14:31:01.000012Z

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