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<javascript:>> > 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<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.
