You may want to look at what core.matrix does in this regard: clojure.core.matrix: single namespace containing the public API clojure.core.matrix.protocols: namespace containing all the protocols clojure.core.matrix.impl.* : namespaces for specific implementations / subsystems + a few utility namespaces
The rationale for this is: it's better for users if the public API is in a single namespace the public API needs to require some of the implementations, so these need their own namespaces the implementations need the protocols, so these have to be in a separate namespace Note how this structure has been driven to some extent by the problem of circular dependencies. On Monday, 15 April 2013 01:21:19 UTC+8, 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 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.
