What really puzzles me is that it doesn't seem to be generally regarded as idiomatic Clojure style to just use top-level (let)s for your "private" globals. This has lots of benefits:
- If you do this you can make them actually, genuinely private, rather than just marked as "please don't use this" - You get more self-documenting source code: (let [x 1] (defn foo [] (...use x...))) is clear about how and where x will be used, while (def- x 1) (defn foo [] (...use x...)) leaves open the possibility that x is important all over the namespace. - You avoid runtime var-deref costs for constants that will never change. I find this style so useful and readable that I'm curious why it isn't more popular in the community at large. On Sep 18, 2:14 am, Rob Lally <rob.la...@gmail.com> wrote: > Thanks for the reference Mark, much appreciated. > > I add the private meta-data by hand, but (defn- foo 2) is so much more > succinct than (def ^:private foo 2) - where ^:private is almost half the > declaration. I also find the placement of the meta-data tag to be intrusive > and disruptive when reading... but that's just a personal peccadillo. > > I find your comments that you don't feel as much need to mark defs as private > as often as defns really interesting, because it is quite different to my own > practice. I tend to look at ^:private primarily as a way to inform users of a > namespace that this def is something they can safely ignore because it is an > implementation detail; you only need to pay attention to this if you're going > to modify the code. > > I've spent 5 mins looking at random source files from a few clojure projects > and I seem to use more defs than most people. I tend to pull out a fairly > high percentage of literals into expanatory defs, whereas the small sample of > files that I trolled through seemed to have a different feel for the tipping > point when a def is appropriate. > > I am surprised at other comments in this chain where people would rather see > the removal of def- than the addition of additional variants of def > derivatives. I'm not arguing that I'm right, or that things should change, > but personally I feel that controlling the exposed surface area of an API is > crucial to comprehensibility and maintainability, and that making > minimisation of surface area as trivial as possible will benefit us all. > > Thanks to everyone for taking the time to write down their thoughts, > > R. > > On 17 Sep 2011, at 16:37, Mark Rathwell wrote: > > > A previous discussion on the topic can be found here [1]. You can > > easily add the private metadata yourself: > > > Clojure 1.2: (def ^{:private true} size 25) > > Clojure 1.3: (def ^:private size 25) > > > I think probably the reason against it is that generally there is not > > as much reason to use a constant, for example, outside of its > > namespace as there is with functions, and therefore more need for > > marking functions meant only for internal use as such (but that is > > just guessing at other peoples' thought processes). > > > [1]http://groups.google.com/group/clojure/browse_thread/thread/80d873ef6... > > > On Sat, Sep 17, 2011 at 10:54 AM, Rob Lally <rob.la...@gmail.com> wrote: > >> Hi all, > > >> Whilst trying to minimise the visible surface areas of namespaces, I've > >> often felt the need for a def- function/macro that marks a def'ed var with > >> :private metadata. An analog of defn-, if you will. > > >> Is there a reason that I shouldn't do this or a reason that it doesn't > >> seem to be a member of the core lib? > > >> In the spirit of Hunt & Thomas' "Select isn't broken", when I encounter > >> something this trivial, useful and absent I tend to conclude that I'm the > >> one who's got things wrong. > > >> Thanks in advance, -- 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