For what it's worth, I've been refactoring big namespaces out into
small, focused namespaces lately. A rough heuristic I've found useful
is that when I require a namespace I should be able to assign it a
name that aids with readability.
So for example:
(ns foo.book)
(defn search [book term]
;;search the book
)
------
(ns foo.stacks)
(defn search [stacks title]
;; search stacks
)
------
(ns foo.library
(require [foo.book :as book]
[foo.stacks :as stacks]))
(defn find-passage [stacks passage title]
(-> stacks
(stacks/search title)
(books/search passage)))
-----
This is all pretty contrived, but it seems to work out in the wild
pretty well. YMMV, and I'm still not settled on this myself, but
hopefully that helps.
Travis
On Sun, Apr 14, 2013 at 2:16 PM, Simon Katz <nomisk...@gmail.com> wrote:
> Whoops — when I said "with an extra [namespace] for each protocol", I meant
> "with an extra [namespace] for each protocol implementation".
>
>
> On Sunday, 14 April 2013 18:21:19 UTC+1, Simon Katz wrote:
>>
>> I'm in the process of trying to work out how I want to use namespaces when
>> implementing libraries or subsystems.
>>
>> I'm aware of several approaches:
>>
>> Use a single namespace, making only the API public (either with everything
>> in a single file or breaking things into multiple files and using `load`).
>> Use implementation namespaces and create an API in a separate namespace
>> (perhaps using Potemkin to simplify the creation of the API).
>> Have lots of smaller namespaces and have the client need to know which of
>> the smaller namespaces to use for what.
>> (And some variations.)
>>
>>
>> I'm fairly happy with large namespaces, so I'm leaning towards using a
>> single namespace.
>>
>> There's one thing I've come across that doesn't fit nicely with putting
>> everything into a single namespace, though. A Google search for "Clojure in
>> the Large" led me to a nice talk by Stuart Sierra
>> (http://vimeo.com/46163090) in which he suggests putting protocols and their
>> implementations in separate namespaces, because, during development
>> reloading a protocol breaks existing instances. (I know Stuart gave a
>> similarly presentation at Clojure West recently, but I don't think the video
>> of that is available yet.)
>>
>> Having the separate namespaces would be fine if I was heading down the
>> route of having the client know about multiple namespaces, but I don't
>> really want to do that. With the single namespace approach (with an extra
>> one for each protocol I define), I end up wanting circular dependencies — a
>> namespace containing a protocol implementation needs to refer to the main
>> namespace in order to mention the protocol, and the main namespace needs to
>> refer to the namespaces containing protocol implementations in order to
>> invoke constructors.
>>
>> Maybe I'll just put everything in a single namespace and be careful about
>> reloading the whole thing when I care about existing instances of protocols.
>>
>> Any other suggestions?
>>
>> Simon
>
> --
> --
> 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/groups/opt_out.
>
>
--
--
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/groups/opt_out.
