On Tuesday, October 3, 2017 at 11:48:04 AM UTC-5, Yuri Govorushchenko wrote: > > 3) I agree that my argumentation was vague but the sentiment still holds > true: I'd like to easily validate keyword args with the same level of > confidence as I can validate positional args. >
Nothing is preventing you from adding additional validation for your keyword args. But that doesn't have to be in spec. > 1,2) > > > Because all map keys are independent and don't rely on each other for > ordering. > > > You can add additional checks to verify stricter things on top of open > specs. You can't add openness to something that is already closed. > > If I understand you correctly, library currently is only concerned with > doing simplest things and that's why `s/keys` is not very strict? But then > I'm not sure if it's the simplest behaviour though since `s/keys` specs > validate 2 things: keys AND (sometimes) values. And that "sometimes" part > makes production code more error-prone. > No, this is not about "simple", it's about creating specs that can grow, rather than break. I would really urge you to watch the hour+ Spec-ulation keynote from Rich at last year's Conj that explains all of this. It doesn't make sense for me to repeat it. He explicitly cover this aspect in the talk. > Is there any chance that in the future core.spec will have additional API > to allow specifying other levels of map validation strictness? Possible > options: > No, see above. It is possible that there will be a variant of keys that will tell you the parts that weren't validated or something like that. > > * Keyset validation strictness: > - open (current behavior, allows putting any additional keys into map) > - closed (map must contain only the listed keys) > not every going to do that for reasons above > * Values validation strictness: > - never validate (i.e. any values will pass, not sure about the use > cases though) > Can do this now with a `map?` or `s/map-of` spec. > - only if spec for key is registered (current behavior) > - always validate values (should fail if there's no spec for value > registered) > > -- 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.
