fwiw, I vote for leaving it. It's extra flexibility and is afaict a fairly easy error to catch. Here's a function that I think should give you every qualified keyword that is used in a spec but that does not have a spec defined for it: boot.user=> (let [kws (atom #{})] #_=> (clojure.walk/postwalk (fn [x] (when (qualified-keyword? x) (swap! kws conj x)) x) (map s/form (vals (s/registry)))) (clojure.set/difference @kws (set (keys (s/registry)))) #_=> ) #{:clojure.spec.alpha/v :clojure.spec.alpha/k} boot.user=>
On Monday, October 2, 2017 at 10:30:57 AM UTC-7, Leon Grapenthin wrote: > > I second this from my experience, using spec quite extensively since its > release. > > We already had some invalid data passing silently because of this. It can > easily happen if you have a typo in the spec. > > Also we never experienced benefits from being able to not spec keys > required in s/keys. It appears to be a pretty obsolete feature, making > vulnerabilities more likely. > > On Monday, October 2, 2017 at 5:37:31 PM UTC+2, Yuri Govorushchenko wrote: >> >> Hi! >> >> I have some noobie questions for which I couldn't google the compelling >> answers. >> >> 1) Is there any way to ensure that the keys I used in `s/keys` have the >> associated specs defined? At compile time or at least at runtime. Maybe via >> an additional library? I could imagine a macro (smt. like `s/keys-strict` >> or `s/map-pairs`, as maps can also be viewed as sets of spec'ed pairs) >> which additionally checks that all keys have specs registered. I'm OK with >> sacrificing some flexibility (e.g. being able to define key specs after map >> specs, dynamically, etc.) in favour of more strictness. >> >> Motivation: I don't fully trust my map validation code when using >> `core.spec`. `s/keys` doesn't require that the key has the spec registered >> to validate its value. Although this may be flexible but in practice can >> lead to errors. Specifically, it's quite easy to forget to create a spec >> for a key, mistype it or forget to require the namespace in which key spec >> is defined (e.g. if the common key specs reside in a dedicated ns): >> >> ``` >> ; totally forgot to define a spec for ::foo >> (s/def ::bar (s/keys :req [::foo])) >> >> ; fooo vs. foo typo >> (s/def ::fooo string?) >> (s/def ::bar (s/keys :req [::foo])) >> >> ; :common/foo vs. ::common/foo typo >> (s/def ::bar (s/keys :req [:common/foo])) >> >> ; didn't require common.core ns (spec for :common.core/foo is not added >> to global registry) >> (s/def ::bar (s/keys :req [:common.core/foo])) >> ``` >> >> These subtle mistakes can lead to map validations passing silently (as >> long as keysets are correct). >> >> Related to this: there're feature requests for Cursive IDE which try to >> address typing and reading mistakes related to keywords, e.g. >> https://github.com/cursive-ide/cursive/issues/1846 and >> https://github.com/cursive-ide/cursive/issues/1864. >> >> After using Schema for a while it's difficult to appreciate the way >> `core.spec` defines it's own global registry which uses keywords instead of >> using spec instances and good old variables, especially since Cursive IDE >> has quite a nice support for variables already. But I think this is another >> topic which was already discussed, e.g. in >> https://groups.google.com/forum/#!topic/clojure/4jhSCZaFQFY ("Spec >> without global registry?"). >> >> 2) What is the motivation for library having a "loose" default behaviour >> of `s/keys` and no "strict" variant at all for spec-ing both keys and >> values at the same tome? I think in majority of cases I'd need to spec both >> keys and values of the map instead of only keys and would expect the >> library to have built-in API for this. Maybe for the future references it >> would be beneficial to add concrete code examples into motivation in the >> core.spec guide ( >> https://clojure.org/about/spec#_map_specs_should_be_of_keysets_only) >> which would better illustrate the described benefits of the current lib >> behaviour? >> >> Thanks. >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.