This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-19
Channels
- # aws (4)
- # aws-lambda (2)
- # beginners (67)
- # boot (38)
- # cider (32)
- # cljs-dev (12)
- # cljsrn (2)
- # clojars (2)
- # clojure (190)
- # clojure-chicago (1)
- # clojure-dusseldorf (2)
- # clojure-germany (1)
- # clojure-greece (3)
- # clojure-italy (5)
- # clojure-russia (6)
- # clojure-spec (47)
- # clojure-uk (10)
- # clojurescript (59)
- # cursive (9)
- # data-science (14)
- # datomic (24)
- # devops (16)
- # emacs (8)
- # fulcro (25)
- # graphql (30)
- # hoplon (123)
- # juxt (15)
- # lambdaisland (2)
- # leiningen (4)
- # luminus (6)
- # lumo (9)
- # off-topic (11)
- # om (7)
- # onyx (8)
- # re-frame (14)
- # reagent (5)
- # ring-swagger (5)
- # shadow-cljs (46)
- # spacemacs (41)
- # specter (8)
- # testing (8)
- # unrepl (31)
- # yada (18)
I am having problems with circular dependencies. Spec strongly encourages splitting your data entities into separate namespaces. I have projects (`project`) which contain entries (`entry`). But entries also refer back to :project/id
via a :entry/project-id
attribute. If I split entries into their own namespace, I have to refer to it when defining what a project
is, but the entry namespace also needs to know what a :project/id
is.
the qualifiers used in spec names do not have to correlate to an actual namespace nor do they have to be defined in that namespace. The word “namespace” is dangerously overloaded in this area.
I think it’s most useful to declare stuff like this in some totally different “domain data” namespace
Interesting. But if they don't correlate to namespaces, I lose the (rather convenient) ::
syntax. I guess the namespaced map reader syntax could make up for that.
schec lets you create aliases to non-existing namespaces, and then you could use the alias to shorten writing specs
you can do this without a library too
(create-ns 'my.cool.thing)
(alias 't 'my.cool.thing)
::t/foo
support for handling keyword aliasing in better ways (without doing that ^^) is something Rich is working on for future release btw
Also, I'm not sure about the new reader syntax for namespaced maps, specifically how it should work with destructuring:
(let [{a :some.ns/a} {:some.ns/a 1}] a) => 1
(let [#:some.ns{:keys [a]} {:some.ns/a 1}] a) => 1
(let [#:some.ns{a :a} {:some.ns/a 1}] a) => error
Is map destructuring with key renaming not supported?a problem with that last one is that the binding form is read in as {some.ns/a :a}
which is sort of backwards from what you want, because the symbol gets namespaced but not the key
@gfredericks Right. But what now, do we give up key renaming? Is that expected/intended?
you can do it the long way, at worst
I have no idea whether there was any intention to make something like this work
Hmm. In that case, the push to use namespaced keys everywhere seems slightly premature.
that’s not valid syntax
the “left” part of destructuring is always the unqualified name of the local being bound
so you want: (let [{a :some.ns/a} {:some.ns/a 1}] a)
(this has worked since Clojure 1.6 I believe)
@alexmiller I am moving to ns-qualified keys everywhere and have many places where I do {:keys [a b c d e f]}
. I was hoping I could do #:some.ns{:keys [a b c d e f]}
and this works well, but what if I additionally want to extract {renamed-g :some.ns/g}
?
you can do both
{:some.ns/keys [a b c d e f], renamed-g :some.ns/g}
I think using the #:some.ns
prefix is kind of confusing in this context - I usually put it inside the map
@alexmiller Oh, so that's the syntax! Thank you, I've never seen it until now.
Means the same thing - just alternate syntax
You can do multiple keys destructuring from different namespaces too
can anyone explain to me why spec doesn't check :ret
specs during instrumentation by default? I know there was a discussion about it a while back, but I'm curious if anyone has a succinct explanation for the decision
IIRC, the rationale is that instrumentation is for checking that you called function X correctly, not for checking that the function X implemented correctly
The recommendation is to use generative testing to confirm that function X works correctly (based on the :ret
and :fn
specs)
I personally disagree with that distinction, since I have functions that can’t be realistically verified with generative testing due to a) side effects or b) disproportional work to get the specs perfectly tuned
Which is why I use https://github.com/jeaye/orchestra 🙂
In my limited experience, instead of using check
to test function X, we ended up just not speccing :ret
or :fn
because they were unverified and I preferred no documentation rather than documentation that was potentially incorrect or out of date
In particular, using orchestra to instrument functions during non-generative testing gives me confidence that my :ret
and :fn
functions are correct, which makes them more valuable as documentation
@alexmiller Is there any plan to allow multiple, or nested namespaces in spec? Example: A spec ::bar/type
declared in the foo.core
namspace that could be referenced as :foo.core/bar/type
? We are currently struggling with a seeming limitation of spec, and while the underlying problems deserves a longer form post, before heading down that path, was just curious if this was something being thought about.
A spec of ::bar/type
would need a namespace alias of bar
available in order to be legal. That could alias any namespace @eriktjacobsen but could be foo.core.bar
if you wanted it to be. Then ::bar/type
would be :foo.core.bar/type
.
Since namespaces are (supposed to be) globally unique and can be arbitrarily "nested" already, I'm not sure what you're asking for...
Thank you Sean. I realize what the current system provides, and how to work around it. I was mostly curious if that specific solution has been talked about... will write up an explanation in a bit.
There is no plan (or need) for any kind of nesting
Thanks for answer. put another way, has there been any thought to allowing a component of a spec identifier that isn't tied to a namespace or part of the unqualified key
That is, please help me understand the problem you're trying to solve
writing the why up now, mostly due to tradeoffs in workflow my team is seeing. Perhaps it just needs a better framework for how we're structuring things, but it could also be solved by what I mentioned.
I think sometimes it's also unclear that keyword qualifiers can refer to Clojure namespaces but don't have to have any relation to them
There is an unfortunate overload and common use for the word "namespace"
Currently namespace aliases also have the unfortunate downside of being tied to the particular case where a qualifier is actually a namespace (I do not expect this to be as constrained in the future)