Fork me on GitHub
#clojure-spec
<
2017-11-26
>
qqq11:11:16

(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

gfredericks14:11:48

would that not go against the "accept arbitrary extra keys" philosophy of spec?

Alex Miller (Clojure team)18:11:34

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.

gfredericks18:11:24

I spose I had always interpreted the openness as partially targeting forwards-compatibility

Alex Miller (Clojure team)18:11:33

It’s still forward compatible to accept more stuff in the future

gfredericks19:11:59

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?

Alex Miller (Clojure team)21:11:08

I would say that’s a non-goal

souenzzo17:11:59

(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.

gfredericks17:11:06

but there's a difference between spec setting that spec on s/keys and a user doing it themselves

arohner19:11:27

Before I go write one, is there a generator for specs? i..e one that will generate (s/cat :x int?)

Alex Miller (Clojure team)21:11:01

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

arohner20:11:34

Not quite. I'm testing https://github.com/arohner/spectrum, so I want to throw arbitrary specs at it

gfredericks20:11:13

once there's a spec spec you could presumably get a generator from it

gfredericks20:11:53

shouldn't spectrum have a spec spec already anyhow? I say that as someone who has never used spectrum

arohner23:11:00

It only needs s/spec? as a spec when using spectrum. To test it, I want a spec generator

taylor21:11:34

curious if there’s been any thought/discussion/work for sharing specs (besides putting them in a shared library)

taylor21:11:55

something akin to XSD? I suppose it’d be limited to what can be expressed in whatever format

Alex Miller (Clojure team)21:11:23

The whole point of using fully qualified namespace keys is that everyone can share specs

taylor21:11:55

yeah, I guess my curiosity is more about alternative mediums/mechanisms for sharing specs?

gfredericks21:11:00

but as soon as you use custom predicates, you need to share code as well

Alex Miller (Clojure team)22:11:37

Which is also fully qualified

taylor21:11:42

I’m thinking of something conceptually similar to Swagger I guess. And yeah it would be a pretty limited subset of spec’s abilities.