Thanks for the clarifications!
On 07/07/2015 11:52 PM, Stuart Sierra wrote:
> Hi pyr,
>
> There are many downsides to hierarchical structure of components and
> systems. The effects are complicated and hard to understand. See, for
> example, the discussion at
> https://groups.google.com/forum/#!t
Hi pyr,
There are many downsides to hierarchical structure of components and
systems. The effects are complicated and hard to understand. See, for
example, the discussion at
https://groups.google.com/forum/#!topic/clojure/2-baBp61XTs/discussion
I recommend that system maps be kept "flat," witho
Hi,
I did get this far indeed. My general question was rather: what's your
general approach ?
Say I happen to have a config that loosely looks like:
{:inputs [{:type :inputA ...} {:type :inputB ...}]
:engine {:engine-opt1 :engine-arg1}
:outputs [{:type :outputA ...} {:type :outputB ..
This could be a nice example of how to use component in practise:
https://github.com/bevuta/pepa
Internally we configure the system map differently. This is based on yet
another library https://github.com/RedBrainLabs/system-graph We have
extended the idea of this library and we now have a file ba
Not sure if this helps, but remember that components and systems are just
records, and records behave like maps. You can construct an empty
`system-map` and then `assoc` components or even `merge` other maps into it.
–S
On Tuesday, July 7, 2015 at 1:00:51 PM UTC-4, Pierre-Yves Ritschard wrote:
Hi,
I've been using an approximation of what component provides in my
applications for quite a while, and I'm trying to see if it's feasible
to move to component, in the sake of homogeneity with the rest of the
clojure world and to see if there are things that make my life easier.
I have a couple