I ran into a case today where I mistyped the keyword in a `keys` spec and
was surprised that validation was not catching invalid data. For my
purposes, it would be sufficient to have a automated test that looks at my
specs and identifies typos in the spirit of
https://gist.github.com/stuarthalloway/f4c4297d344651c99827769e1c3d34e9
However, I ran into a problem because my `keys` specs are often generated
by the various multi-methods in a multi-spec. I took a stab at implementing
a version of a "spec linter" that would catch typos in multi-specs, but I
couldn't get anything that worked (at least in Clojurescript, I haven't
tried implementing it in Clojure).
Is it possible to write a CLJS linter that will catch the missing spec in
the example below? If so, great! If not, I worry that the recommended
approach of adding a linter on top of spec may not be sufficient in this
case.
(s/def ::name string?)
(defmulti msg :msg-type)
(defmethod msg :greeting [x]
(s/keys :req-un [::name]))
(defmethod msg :count [x]
(s/keys :req-un [::num]))
(s/def ::msg (s/multi-spec msg :msg-type))
(I suppose it's always going to be possible to write a linter that walks the
Clojure code and understands the semantics of the above macros, but I was
hoping I could write one using the data contained in the spec registry instead)
Ben
On Thursday, November 23, 2017 at 7:09:15 AM UTC-7, Nico Schneider wrote:
>
> Hello everyone,
>
> On Thursday, 16 November 2017 23:29:56 UTC+1, John Newman wrote:
>>
>> [...] when we constrain maps in that closed way, aren't we creating some
>> new subtype of a map, with fundamentally different semantics? If you are
>> going to fully close a map, you might as well use a deftype and make a
>> custom object and not call it a map, right?
>>
>
> Just to add my two cents, I've been following the discussion and this has
> been my thinking for quite some time. Is it not a valid argument? Having a
> validation mechanism pick only certain keys, or ensuring that keys in a map
> are specced, look as trivial to me than other data wrangling we do in
> Clojure. My (preliminary) conclusion in cases like this is to build
> validation tooling around spec, instead of using it directly.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
