On Saturday, October 15, 2016 at 10:17:15 PM UTC-5, Josh Tilles wrote:
> I’ve got a couple questions for Alex Miller and/or the other Cognitect
> 1. *Are single-segment namespaces still “bad” when it comes to
> registering specs under qualified keywords?*
> I will give a qualified *sometimes*. :) There are several possible
contexts and I would not give the same answer for all of them.
If you are creating a library, particularly a library that will
interoperate with other libraries, I would strongly recommend using
namespaced keywords with sufficient namespaces that you will not clash with
others. In some cases, a library may be well-entrenched or well-known
enough to make a single namespace sufficient. For example, consider ring
request/response maps and middleware, which is a prime example for
interoperable libraries. If you were creating a Ring session middleware,
you might want to use namespace keys in the request like
:ring.session/token (or whatever, don't compare this to any actual existing
lib). Here, "ring" is probably sufficiently established to be unambiguous
and "ring.session" scopes you to something narrower. I think that's highly
preferable to just :ring/token.
If you're creating a brand new library designed for interoperation with
other libs, I would strongly consider using more than a single segment
namespace that combines some notion of organization and project.
If you're creating an internal application, I think you're free to do
whatever you want. So a single segment path in the context of a single
application might be totally fine - :domain/email. As long as you're not
colliding with some library and you coordinate in your private scope, do
what communicates the best for you. If you have multiple internal projects
that need to coordinate, you might need more namespace segments to
> 1. In the past, single-segment namespaces have been discouraged in the
> Clojure community—both because of Java interop concerns and because of the
> possibility of name-collision when combining projects. However, many of
> spec examples I’ve seen have demonstrated registering specs under keywords
> qualified by a single-segment namespace. For example, the guide’s
> section on multi-spec <http://clojure.org/guides/spec#_multi_spec>
> defines :search/url and :error/message. Is that because
> namespace-qualifiers of specs shouldn’t be under the same constraints as
> namespaces used to organize code?
> These short names are mostly chosen to make the examples brief and
readable, although they might be sufficient when used in an application as
mentioned above. However, I think it is important to note that your
namespace qualifiers do NOT need to correspond to your code. You can use
create-ns and alias to create shorter names in the context of a particular
namespace just to save typing, while still using namespaces independent
from your code. We are considering changing alias to automatically create a
ns if it does not exist (see http://dev.clojure.org/jira/browse/CLJ-2030).
> 1. I’m *guessing* not; it seems more likely that the single-segment
> namespaces have been used only to keep the code snippets straightforward
> and focused on spec, and that “real” code would alias (e.g.)
> my-company.my-project.search as search before defining a ::search/url
> 2. *When designing, how do you decide whether to use a simple keyword
> or a qualified one?*
> There’s an interesting mix of the two in the official docs and in the
> code for spec itself. For example: the spec rationale
> <http://clojure.org/about/spec#_sequences> and guide
> <http://clojure.org/guides/spec#_sequences> both use simple keywords
> when labeling path components, and spec reports invocation errors for
> instrumented functions with maps that exclusively use qualified keys at
> “root” but simple keywords appear as values
> and as keys in nested maps
> Path components are simple as they exist in the context of a particular
spec which has a fully-qualified name. I suspect in general the other
choices mostly follow that pattern - fully-qualified when they are used
without context or when they might be intermingled with other keys and
unqualified when used as keys in the scope of some other context. That
said, things may not be 100% consistent in every possible case.
Hope that helps!
> Thank you for your help. I really appreciate it.
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to email@example.com
Note that posts from new members are moderated - please be patient with your
To unsubscribe from this group, send email to
For more options, visit this group at
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.