I’ve got a couple questions for Alex Miller and/or the other Cognitect folks.
- Are single-segment namespaces still “bad” when it comes to registering specs under qualified keywords?
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 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?
- 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.
Thank you for your help. I really appreciate it.
Best,Josh
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.That isn't me. I'm just chiming in from the peanut gallery. Must of my "experience" so far stems from convertingmy toy projects from prismatic schema to spec.
- Are single-segment namespaces still “bad” when it comes to registering specs under qualified keywords?
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 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?This part of the question interests me a lot.I've found myself defining a lot of specs in, say, the com.foo.project.schemas namespace.This used to be extremely convenient, due to ns aliases.I think the docs say that I should be able to set up the same kind of basic aliasing so that I canjust refer to those specs as (for example) :c.f.p.s/whatever. But I haven't been able to actuallyget that to work yet.
I’ve got a couple questions for Alex Miller and/or the other Cognitect folks.
- Are single-segment namespaces still “bad” when it comes to registering specs under qualified keywords?
- 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 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?
- 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.
- 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 and guide 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 and as keys in nested maps.