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 <jeroentjevand...@gmail.com> 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.platz@place.works> 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 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. > > > -- > 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 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+unsubscr...@googlegroups.com. > 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.
