Fork me on GitHub
#clojure-spec
<
2017-02-02
>
villesv21:02:18

Hi, I am wondering if maybe I have stumbled across an issue in clojure.spec. I have perused the issue list but have found nothing that I think describes the issue at hand for me.

villesv21:02:06

A small example:

(s/def :some.ns.1/k string?)
(s/def :some.ns.1/m (s/keys :req [:some.ns.1/k]))

(s/def :some.ns.2/k string?)
(s/def :some.ns.2/m (s/keys :req-un [:some.ns.2/k]))

(s/explain-str :some.ns.2/m {:k "1"
                             :some.ns.1/m {}})
;; => "In: [:some.ns.1/m] val: {} fails spec: :some.ns.1/m at: [:some.ns.1/m] predicate: (contains? % :some.ns.1/k)\n"

villesv21:02:05

My point being, although I am checking (doesn't matter if I use s/explain-str, s/assert etc) for :some.ns.2/m - clojure.spec ends up also validating another spec.

villesv21:02:34

That is, although :some.ns.1/m is in there and not conforming to spec - I did not expect it to be checked for. I also noticed that this happens both when I use :req-un and :req for :some.ns.2/m

villesv21:02:58

I am thinking this is a bug

villesv21:02:00

Hmm, no seems I am mistaken, I found this in the spec source docs for clojure.spec/keys: > In addition, the values of all namespace-qualified keys will be validated > (and possibly destructured) by any registered specs. Note: there is > no support for inline value specification, by design. How have I not stumbled across this before?

ghadi23:02:29

dunno -- it's in the guide too , I'm pretty sure. Best way to understand is that namespaced keys have program-global meaning