Thanks for the suggestion to look at the ClojureWerkz libraries. I took a
quick look at the user documentation for three of them (Monger, Welle and
Quartzite), and in all cases they showed examples of client code requiring
multiple namespaces.
On Monday, 15 April 2013 16:45:47 UTC+1, travis
Thanks for the pointer to
tools.namespacehttps://github.com/clojure/tools.namespace —
it looks really useful. And if I follow the advice there to always create
new instances of records after a refresh, it will simplify my decision on
how to organise namespaces — there's no longer a need to
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
For what it's worth, I've been refactoring big namespaces out into
small, focused namespaces lately. A rough heuristic I've found useful
is that when I require a namespace I should be able to assign it a
name that aids with readability.
So for example:
(ns foo.book)
(defn search [book term]
I'm considering going this way. I definitely like that it keeps things
simpler for me (the implementer), but clients have to know about multiple
namespaces rather than a single namespace and I don't like that.
I must say I'm finding it hard to decide which way to go.
On Monday, 15 April 2013
I definitely like that it keeps things simpler for me (the implementer), but
clients have to know about multiple namespaces rather than a single namespace
and I don't like that.
Ah, right - I've mostly been working in application code, not
libraries. That said, I think the heuristic still
...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 don't universally recommend this any more. You still have to be
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
Whoops — when I said with an extra [namespace] for each protocol, I
meant with an extra [namespace] for each protocol implementation.
On Sunday, 14 April 2013 18:21:19 UTC+1, Simon Katz wrote:
I'm in the process of trying to work out how I want to use namespaces when
implementing libraries
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
10 matches
Mail list logo
