Thanks for the suggestion to look at the ClojureWerkz libraries. I took a quick look at the user documentation for three of them (Monger, Welle and Quartzite), and in all cases they showed examples of client code requiring multiple namespaces.
On Monday, 15 April 2013 16:45:47 UTC+1, travis vachon wrote: > > > I definitely like that it keeps things simpler for me (the > implementer), but clients have to know about multiple namespaces rather > than a single namespace and I don't like that. > > Ah, right - I've mostly been working in application code, not > libraries. That said, I think the heuristic still works - I'd > definitely try writing some code that consumes your library, either in > tests or in a dummy project, and apply the same rule: can you give the > namespace a name that makes function calls clearer? Given a single > name, are there pieces that feel out of place? > > This is a topic that comes up a lot, and I think that's at least > partially because different domains and library styles call for > different strategies. An ideal library that does one thing really well > might indeed be a good candidate for one big public namespace, but of > course internally it might make a lot of sense to break the > implementation up into focused modules. > > You might check out the clojurewerks libraries for some insight from a > group that has written quite a few libraries: > > http://clojurewerkz.org/ > > Travis > > On Mon, Apr 15, 2013 at 11:23 AM, Simon Katz <nomi...@gmail.com<javascript:>> > wrote: > > I'm considering going this way. I definitely like that it keeps things > > simpler for me (the implementer), but clients have to know about > multiple > > namespaces rather than a single namespace and I don't like that. > > > > I must say I'm finding it hard to decide which way to go. > > > > > > On Monday, 15 April 2013 15:31:49 UTC+1, travis vachon wrote: > >> > >> 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 <nomi...@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 clo...@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+u...@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+u...@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 clo...@googlegroups.com<javascript:> > > Note that posts from new members are moderated - please be patient with > your > > first post. > > To unsubscribe from this group, send email to > > clojure+u...@googlegroups.com <javascript:> > > 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+u...@googlegroups.com <javascript:>. > > 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.
