I believe by "several different mem-dbs" he means different instances, not implementations, i.e. they differ by name and (maybe) config, but share an implementation.
There are two ways this can happen: two system graphs in the same clojure runtime, or one system graph that uses the same service-type twice. In Component, the first case is handled by making a separate Component map; the second by adding a new key to the map. In mount, the first case is AFAIKT not possible (maybe some swap-with-states trickery?), and the second by adding a new defstate var somewhere. In general, what Component does with system maps, map keys and records mount does with namespaces. The upside is you don't have to be as manual and explicit about instances, names, dependencies, instantiation, etc (just use normal namespace machinery and accept initialization as a side-effect of require). The downside is that namespaces are singletons, so your system must be a singleton too. On Tuesday, April 19, 2016 at 7:46:44 AM UTC-5, Brian Platz wrote: > > > Jeroen, > > Happy to talk more about it on Slack. > > No matter what you are `def`-ing something somewhere. For Component I’d > `def` a big config map, and I do the same with Mount. My advantage with > Mount in the REPL is that I can have local vars for ‘components’ that are > easy to reference (but still driven from the main config map). In Component > I’d accomplish this by outputting what I need to a var, usually in the > ‘user’ namespace that I could get a handle to. > > As for several different `mem-db`s, if you mean swapping them out for > dev/testing, that is explained here: > https://github.com/tolitius/mount#swapping-alternate-implementations > > -Brian > > > > On Apr 19, 2016, at 6:03 AM, Jeroen van Dijk <jeroentj...@gmail.com > <javascript:>> wrote: > > Hi Brian, > > When looking at the Readme of Mount (I think) I already see global state > backed in. > > (defstate ^{:on-reload :noop} > mem-db :start (connect config) > :stop (disconnect mem-db)) > > > Do I misunderstand this or do we just disagree on what global state is? > What if I want to have several (different) `mem-db` instances, how would > that work? > > > > On Fri, Apr 8, 2016 at 4:25 PM, Brian Platz <brian...@place.works > <javascript:>> wrote: > >> >> >> This is also something that wouldn't be possible with Mount as this >> library seems to promote global state. >> >> As a recent switcher from Component to Mount, and without trying to >> change the thread's topic into a this vs. that -- I'll simply say that I >> don't believe any of these tools promote global state, it is people who >> code global state, and that can be with any of these tools... or likewise >> avoided with any of these tools. >> >> Some tools (i.e. Component) probably make it more difficult to have >> global state, but I think it is heavy handed. For projects with a lot of >> components, I would spend a lot of time backtracking components all feeding >> into each other to figure out where some var was when working in REPL. I'd >> also repeatedly deal with errors when adding new components as I didn't set >> up the dependencies correctly at first... just several interlocking pieces >> that all need to be coordinated, and I sometimes forget one (or two). >> >> Mount probably makes it a little easier to have global state, but that is >> up to the developer - I have no more global state than I had before the >> switch. I find it easier to work in REPL and get access to a var, or conn, >> etc. when I need to eval something, and I think all these components are >> primarily there to make the REPL workflow better. Also, I'm out of the >> business of managing my dependencies, which my challenges might just root >> from an absent-mindedness that I possess. Once it is in production, the >> component stuff matters very little anyhow. >> >> All to say that these tools, assuming they provide the feature needs that >> have been outlined well in this thread, should not make anything 'not >> possible' and can have as much or as little global state as the developer >> chooses to code in. I cringe a bit when I repeatedly see that Mount >> promotes global state, I think that is a falsehood. >> >> -Brian >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com <javascript:> > 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/hYFEpJ6w80k/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+u...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- 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/d/optout.
