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.

Reply via email to