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
