Fork me on GitHub
#clojure-spec
<
2019-10-05
>
misha14:10:45

are there any pre-requisites? so you wouldn't have to baby-sit too much

roklenarcic20:10:21

Seems there's an inconsistency about how conforming works if you have qualified or unqualified s/keys. Given specs:

(s/def ::a (s/conformer str))
(s/def ::b (s/keys :req []))
(s/def ::a1 (s/merge (s/keys :req-un [::a]) ::b))
(s/def ::a2 (s/merge (s/keys :req [::a]) ::b))
You get:
(s/conform ::a1 {:a 1})
=> {:a 1}
(s/conform ::a2 {::a 1})
=> #:clj-rest-client.core{:a "1"}
Weird.

seancorfield21:10:55

@roklenarcic Interesting. I tried it with the latest Spec 2 and it's the same. Also the same behavior using s/schema (with [::a] for qualified keys and {:a ::a} for unqualified keys).

ikitommi21:10:44

I think the reason is that clojure.spec.alpha/merge separately conforms each merged spec, then merges the results, so the unconformed value from the lateer overrides the result

Alex Miller (Clojure team)21:10:52

Merge only confirms the last spec

ikitommi21:10:21

Second works because all namespaced are always confirmed, even if they are part of the spec.

seancorfield21:10:53

Ah yeah. That makes sense!

roklenarcic22:10:21

How? Makes no sense at all to me that it matters whether I use namespaced keys or not.

roklenarcic22:10:06

Alex says that merge only conforms the last spec, but if I s/merge multiple s/keys specs that use conformers and that use namespaced keys, all the keys are conformed not just the ones from the last merge argument