This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-06
Channels
- # architecture (25)
- # bangalore-clj (1)
- # beginners (21)
- # boot (45)
- # cljs-dev (38)
- # clojure (272)
- # clojure-austin (7)
- # clojure-finland (7)
- # clojure-france (3)
- # clojure-italy (7)
- # clojure-japan (1)
- # clojure-russia (13)
- # clojure-spec (36)
- # clojure-uk (31)
- # clojurescript (96)
- # core-async (15)
- # cursive (16)
- # datascript (3)
- # datomic (97)
- # emacs (107)
- # hoplon (16)
- # jobs (9)
- # keechma (1)
- # luminus (1)
- # off-topic (19)
- # om (39)
- # onyx (15)
- # pedestal (3)
- # planck (22)
- # protorepl (4)
- # re-frame (20)
- # reagent (3)
- # ring-swagger (25)
- # specter (26)
- # test-check (19)
- # testing (1)
- # untangled (381)
I used s/merge
to extend a spec with additional keys, but when I s/conform
, it seems that only the newly-added keys get conformed, not the original spec. In general, it seems that while s/valid
validates the entire merged spec, s/conform
only uses the last spec passed to s/merge
. Is this something to be expected?
After reading the discussion several times, I don't understand what I'm supposed to do. Is the point here that unqualified keys are second-class citizens and should be phased out? Or is there another solution to merging specs and having conform work?
Indeed, s/and
works just fine. I'm making notes to never use s/merge
, but I don't understand why "it does not flow conformed results". Why would one want it to behave that way?
I'm sure there was a reason, but to explain my thinking: having read both the s/merge
docstring and the clojure.spec guide, I did not expect s/merge
to be a lossy operation which will drop some of my conformers. Especially since it is called just like a map merge
operation and looks like one. If this is really intended, I think it deserves a warning in both places.
so yeah, it's one of the oddities in spec. I also find this quite counter-intuitive (no matter the reason/motivation behind this)
I think in general case this is impossible, not only in spec. User-defined functions can be passed to s/def
.
But in a limited way, you can generate values for spec A and validate them against spec B.
I guess that makes sense. One of the major visions for spec is to confirm compatibility between, say, your code and a new version of a dependency (in a world where they both are well spec'd). Is the expected way to do that to use test.check
to confirm it works for lots of random values?
I don't think so
I think the main idea was static analysis of keysets and regexes
I think specs can theoretically be comparable in finite time, since AFAICT they describe regular languages
I might be wrong tho. if spec accepts CFGs then comparing specs is definitely not possible
@bronsa What about (s/def ::a (fn some-fn [v] ...))
and (s/def ::b (fn different-fn [v] ...))
- how do you compare Clojure functions?
unless you can get away with saying "different functions are always completely different"
@bronsa the sequence regexes aren't technically regular as they can self-reference
I'm not sure if that's an intentional feature though
(s/def ::car (s/keys :req [:document/number :license/plate]))
But I just need one of these keys
You can use or in :req - check the doc string or the guide
(s/def ::car (s/keys :req [(or :document/number :license/plate)]))
— note this allows for cars with both document number and license plate so if you specifically want exclusive-or, you need to s/and
another check onto that.
Similar question / answer from 5 days ago http://stackoverflow.com/questions/42530452/clojure-spec-validating-contents-of-maps