> 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 <nomisk...@gmail.com> 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 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.
