Thanks — this works nicely. I think it's a shame that if I want to make protocol methods public I have to use the "Use implementation namespaces and create an API in a separate namespace" approach, but I guess this is the only way.
On Monday, 15 April 2013 01:52:37 UTC+1, Mikera wrote: > > 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.
