This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-26
Channels
- # beginners (17)
- # boot (3)
- # cljs-dev (2)
- # cljsrn (3)
- # clojure (52)
- # clojure-austin (1)
- # clojure-poland (4)
- # clojure-russia (29)
- # clojure-spec (25)
- # clojure-uk (5)
- # clojurescript (39)
- # cursive (29)
- # data-science (5)
- # datomic (5)
- # fulcro (21)
- # graphql (1)
- # hoplon (20)
- # off-topic (5)
- # pedestal (1)
- # perun (3)
- # protorepl (2)
- # re-frame (7)
- # ring (1)
- # shadow-cljs (19)
- # unrepl (10)
- # vim (4)
(s/keys ::req [])
<- notice the ::
instead of :req
is there a way to have that throw an error ?
sometimes, I define that, then I create objects, and they satisfy the spec ... because it's a map with no requirements since ::req
is silently ighnroed
Sure, file a jira
would that not go against the "accept arbitrary extra keys" philosophy of spec?
I wouldn’t necessarily put it in the spec for keys, but it’s reasonable to validate it in the function. It’s not like this is getting passed to anything else.
I spose I had always interpreted the openness as partially targeting forwards-compatibility
It’s still forward compatible to accept more stuff in the future
right, but then code targeting the future API can't use the older version if it happens to be around maybe that's not a useful thing? you just want backwards compatibility so you can use the newest of all the versions that each part of the code wants?
I would say that’s a non-goal
(s/fdef s/keys
:args (s/+ (s/cat :k #{:req :opt}
:v coll?)))
=> clojure.spec.alpha/keys
(s/keys ::req [])
CompilerException clojure.lang.ExceptionInfo: Call to clojure.spec.alpha/keys did not conform to spec:
In: [0] val: :user/req fails at: [:args :k] predicate: #{:req :opt}
#:clojure.spec.alpha{:problems [{:path [:args :k], :pred #{:req :opt}, :val :user/req, :via [], :in [0]}], :spec #object[clojure.spec.alpha$regex_spec_impl$reify__2436 0x2fa7a99c "clojure.spec.alpha$regex_spec_impl$reify__2436@2fa7a99c"], :value (:user/req []), :args (:user/req [])}, compiling:(/tmp/form-init4270935507983081845.clj:1:1)
(s/keys :req [])
@qqq
@gfredericks sure. But you can do 🙂
Maybe in future versions of spec, this spec will be wrong. But for now, it's a usefull build-time error.but there's a difference between spec setting that spec on s/keys
and a user doing it themselves
Before I go write one, is there a generator for specs? i..e one that will generate (s/cat :x int?)
The spec specs in CLJ-2112 are imo the right direction for that. The specs there are not yet good enough to be used for this in general
https://github.com/stathissideris/spec-provider what you're looking for?
Not quite. I'm testing https://github.com/arohner/spectrum, so I want to throw arbitrary specs at it
once there's a spec spec you could presumably get a generator from it
shouldn't spectrum have a spec spec already anyhow? I say that as someone who has never used spectrum
It only needs s/spec?
as a spec when using spectrum. To test it, I want a spec generator
curious if there’s been any thought/discussion/work for sharing specs (besides putting them in a shared library)
something akin to XSD? I suppose it’d be limited to what can be expressed in whatever format
The whole point of using fully qualified namespace keys is that everyone can share specs
yeah, I guess my curiosity is more about alternative mediums/mechanisms for sharing specs?
but as soon as you use custom predicates, you need to share code as well
Which is also fully qualified