I feel your pain. I also run up against this time and time again and view it as a significant limitation -- one which often forces me to contort the structure of my Clojure programs into something less natural. And as the Clojure language grows, the problem becomes even more acute.
For example, consider specs. One common recommendation is to put your specs in a separate, parallel namespace. However, implementing specs often requires domain-specific logic, i.e., functions from your main namespace. And your main namespace often requires specs because the logic of your functions may need the specs in order to conform some data as part of its processing. So what to do? These kinds of things happen a lot in my experience, and a solution would be incredibly valuable. Best solution I've found is to hoist mutually dependent things into a common namespace and use potemkin to clone them into a more logical partitioning. But that's never been very satisfactory to me. -- 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/d/optout.
