I agree that namespaces should be designed to be consumed, but that can be 
pretty taxing on the developer.  In my libraries, I tend to split the 
functions into whatever sub-namespaces I want to keep the organization easy 
for me, and then import all the functions I want to expose into a 
higher-level namespace.

For example, in Aleph I have HTTP functionality implemented in 
aleph.http.client, aleph.http.server, aleph.http.websocket, etc. but all the 
useful functions are gathered together into aleph.http.  This means that I 
don't have to navigate a monolithic namespace, but the users of my library 
don't have to declare a dozen namespaces to get anything done.  I find this 
approach scales for me pretty well, and I haven't heard any complaints from 
the people using my libraries about the organization.

Zach

-- 
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

Reply via email to