I guess a related concern is abstraction. I notice I often have functions which work at different levels of abstraction in the same ns which makes me uncomfortable. In OO land they would be package level or even instance classes. I haven't yet found a way to solve this in clojure land.
To be explicit, I have a defn which calls a defn which calls a defn which calls ...., having all of those defns public doesn't capture the hierarchy of abstraction. On 14 May 2015 17:14, "Sean Corfield" <s...@corfield.org> wrote: > On May 13, 2015, at 11:07 PM, Brian Craft <craft.br...@gmail.com> wrote: > > > http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)#As_information_hiding_mechanism > > > In an environment where you can’t trust your co-workers(!), you certainly > want to hide *mutable* data so they can’t modify your objects’ state. When > you remove mutability, there’s a lot less damage they can do and they it’s > really more about which pieces of the system do you not want them to "use" > (in terms of functional APIs). > > The "Clojure Way" seems to be "just make all functions public — they might > be useful to someone" although that then restricts what refactoring you can > do in future compared to exposing a smaller surface area. Since you can > always call private functions anyway (and access private data directly), > you really need conventions — and code review — to prevent abuse, and at > that point having foo.api and foo.impl namespaces — and a convention to not > use foo.impl outside of foo.api — is very reasonable and even automatically > enforceable through tooling. > > When I first started doing Clojure (five years ago — yikes! feels like > yesterday!) I still had an OOP mindset around data hiding and I used > *defn-* and *^:private* a lot (well, *^{:private true}* back then I > guess). These days I tend to make all my functions public and use > namespaces if necessary to clearly delineate APIs vs implementations. A > *def* of immutable data tends to be public too. It’s rare that I feel the > need to make things private since immutability means no one can "abuse" my > data or my functions. > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) > > > > -- > 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 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.
