Thanks. I was hoping that someone would see a way to organize the namespaces to avoid circular dependencies, but perhaps there's simply no way to do that short of what I already outlined.
I especially appreciate the pointer to Potemkin. Just reading through the "apologia", it sounds like it is meant to solve exactly the kind of problem I frequently find myself in. It seems that any time I work with a large-ish Clojure code base, I find myself wrestling with how to chop into namespaces, and it is always unpleasant and non-trivial because of the circularity constraints. I feel Zach hits the nail on the head when he says that namespaces conflate implementation partitioning with usage. I have often found this to be a problem when consuming other libraries, such as incanter, where it can sometimes be difficult to remember where different functions reside. The incanter tutorials all solve this problem by "use"ing all of the related namespaces, but that's not always a viable solution. If there are any more general concepts or techniques I should keep in mind when partitioning my implementation into namespaces while maintaining a front-end that users can require from just one namespace, I'm all ears. On Wed, Dec 12, 2012 at 9:46 AM, Karsten Schmidt <i...@toxi.co.uk> wrote: > There's also Zach Tellman's Potemkin lib, which can be used to > immigrate individual vars: > https://github.com/ztellman/potemkin > > -- 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
