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 
> folks.
>    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 
> the 
>    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 
>    spec.
> Yes. 

>    1. 
>    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 
> the 
>    “root” but simple keywords appear as values 
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fclojure%2Fclojure%2Fblob%2Fclojure-1.9.0-alpha13%2Fsrc%2Fclj%2Fclojure%2Fspec%2Ftest.clj%23L394-L402&sa=D&sntz=1&usg=AFQjCNG7WXKKDD045BnZVx-2qTsrDQ8QuA>
>    and as keys in nested maps 
> <https://github.com/clojure/clojure/blob/clojure-1.9.0-alpha13/src/clj/clojure/spec.clj#L205>
>    .
> 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.
> Best,
> Josh

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
For more options, visit this group at
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/d/optout.

Reply via email to