This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (73)
- # boot (20)
- # chestnut (8)
- # cider (36)
- # clara (37)
- # cljs-dev (21)
- # cljs-experience (1)
- # cljsrn (2)
- # clojure (163)
- # clojure-austin (3)
- # clojure-dusseldorf (6)
- # clojure-finland (1)
- # clojure-ireland (4)
- # clojure-italy (45)
- # clojure-russia (9)
- # clojure-spec (47)
- # clojure-uk (20)
- # clojurescript (107)
- # cursive (24)
- # data-science (4)
- # datomic (4)
- # defnpodcast (1)
- # fulcro (1)
- # heroku (3)
- # jobs-discuss (4)
- # juxt (52)
- # lein-figwheel (1)
- # leiningen (4)
- # lumo (37)
- # midje (5)
- # off-topic (16)
- # onyx (15)
- # portkey (11)
- # re-frame (112)
- # reagent (12)
- # rum (1)
- # specter (35)
- # uncomplicate (6)
For a (publicly available) library, yes, I agree that a clear public/private separation is useful from a documentation and support point of view. Otherwise there's not much point. And even for the library API, it's a toss up between using public and private in one ns vs using a fully public ns and an "implementation" ns (clearly documented as such), in my opinion.
(however, when discussing contrib library organization with Cloure/core folks, it seemed they lean heavily toward avoiding the public vs implementation ns approach)
I don’t think there is consensus - there are examples of every option from clojure/core people
I'll rephrase then: when I asked for feedback on
java.jdbc, I got very strong feedback from the Clojure/core folks who expressed a preference back then, that a "private namespace" or "implementation namespace" was not considered "good practice". I didn't push for justification, I just took it at face value.
It definitely feels like something that would be nice to get some design guidance on -- from the wizened ol' Cognitect elder statesmen 🙂
Yeah, I was a bit surprised at the strength of the feedback on
java.jdbc's impl namespace at the time... I didn't think there was really as much consensus as the feedback indicated.
I think it would be great if Cognitect could perhaps articulate a core of "best practices" or at least the pros/cons of common approaches -- and cover those in a conference talk, to get the community discussion going around that sort of thing.
I’d say the only approach that I actively don’t like is one public api namespace, with vars imported from elsewhere via potemkin. But I understand other people do like that style and I’ll respect their opinion. :)
Clojure seems to have woefully little guidance on style and code organization overall.
collectively, people at Cognitect have written like a dozen books and dozens of presentations on it
Maybe Clojure Applied covers that (I only just bought that -- haven't started it yet).
Hmm, not about this topic in particular, that I can remember. He's certainly done some strong opinion pieces on other topics 🙂
If I worked for a company that was in the business of advising others, I'd probably write / talk more!
it’s always a struggle to balance the “doing things” with the “talking about doing things”
I'm just anti-private-cars because it makes unit testing, extension, and REPL debugging harder.
Yeah I wish there was an expressable relationship between test and regular name space letting the private vars be used explicitly
When I first started writing Clojure, I used private functions a lot. Over time I stopped using them and I almost never write a private function now (except for the library case above).
I've tended to find that I end up wanting to reuse functions that I initially thought should be private -- and since they're usually pure functions of their arguments, there's really no downside.
I find it to be heavily context dependent and I do all of them (all public, public/private, split api/impl namespaces) depending on the situation
Hi... I would like to know what how do you guys manage state, use things like compose or mount, or just use a simple def atom?
what in-memory mutable state our apps have tends to be in an atom in a component. there's rarely more than like one of those though. mostly state is stored in external systems
States like db connection, rmq connection (to use a single connection) a simple atom? That is it?
I'm making a service, but I'm isolating things like db connection, and others just use it
unless the connection requires refreshing I wouldn't think of it as state, it would just be a field on a component. if it required refreshing then it would be an atom in a field on a component
ya, I think his talks on that are currently the most common way to manage things like db connections in clojure apps
ie as in, the state is all passed through via function arguments, but initializing that big state map is somewhat taken care of for you
components are isolated yes - you can create two of the same component with separate configs, or the same config but they each have their own state
btw a big advantage is for testing - with component all you need to do to “mock” in a test is to provide a hash map with the right keys on it
tomorrow, when you change something, do you know without running the app (or worse yet, deploying it) what other thing it might have broken by changing its behavior?
and really a test is the simple version of that 😄 - take what you did in the repl, wrap some test/is calls around it
If you write small libs.. tests become pointless, but to do that you must write an excellent documentation so ppl doesn't get lost
on the other hand, this is mostly opinion but I agree with Rich Hickey that “test driven development” is like “guard rails driven development” - it’s good to have barriers that let you know when they are crossed and avoid certain catastrophic mistakes (or catch them sooner when it’s easier to address), but centering your dev process around those barriers seems a bit much