This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-02
Channels
- # aleph (6)
- # beginners (37)
- # boot (415)
- # cider (17)
- # cljs-dev (79)
- # cljsjs (3)
- # cljsrn (18)
- # clojars (3)
- # clojure (34)
- # clojure-france (6)
- # clojure-italy (1)
- # clojure-korea (1)
- # clojure-russia (22)
- # clojure-spec (64)
- # clojure-uk (47)
- # clojurebridge (6)
- # clojurescript (61)
- # clojurex (1)
- # cloverage (11)
- # component (6)
- # cursive (73)
- # data-science (6)
- # datascript (4)
- # datomic (38)
- # editors (1)
- # emacs (4)
- # events (16)
- # funcool (5)
- # garden (3)
- # hoplon (17)
- # jobs (2)
- # klipse (74)
- # off-topic (3)
- # om (81)
- # onyx (35)
- # parinfer (4)
- # pedestal (1)
- # perun (20)
- # planck (9)
- # proton (1)
- # re-frame (17)
- # reagent (3)
- # ring-swagger (1)
- # rum (7)
- # untangled (63)
- # vim (8)
Hi, #clojure-spec! came to ask: what's the difference between clojure.spec/map-of and clojure.spec/every-kv?
@vandr0iy map-of
checks all the entries of the map, while every-kv
samples a subset of the entries
Any thoughts on writing separate specs for input data that needs to be coerced, vs using spec/conformer?
That's what I'm finding to be the case
The only problem is I'm duplicating my validation logic, because I want to be able to detect invalid data at the point of entry
I'm using spec in both cases because the generative testing is super-helpful
it doesn't look immediately possible with :fn
unless I pass context back through the return value
@vandr0iy additionally, every-kv will not conform its keys or values (because it doesn’t check all of them) whereas map-of will conform all values (and optionally all keys)
@drewr don’t write fns with side effects? :)
seriously though, you might look at the stub and replace options on stest/instrument
particularly for the case where you are checking a function that calls a side-effecting function
you can stub or replace it instead
I didn't think to look at instrument
, though, because this goes farther than just args checking
seems like something that would happen with test.check... ie, a function that somewhere ends up writing a value to a db, and I need to make sure that value is deleted (or the db is removed)
you should instrument, then check
then unstrument
right now I'm doing the whole enumerate-namespace
-> check
-> summarize-results
dance, sounds like I need to break out of that pattern
@lopalghost I played around with those issues in https://github.com/gfredericks/schema-bijections; I'd love to see that sort of thing implemented for spec
i haven’t used the stub-and-replace options alex mentions, so maybe you guys just mean that using them necessitates breaking out of the pattern he gives
@gfredericks I think spec/conformer is a pretty good solution to the problem of coercing back and forth, at least
The problem is you lose information about the input, making explain and check less useful
I've tried writing some DSLs to generate specs, but I was never really happy with them
Yeah, I remember an earlier conversation that ended up recommending mapping to new specs rather than just conforming
But spec isn't good at, e.g., describing maps with string keys, though :/
I often wonder why namespaced keys couldn't just be a collection of keywords, since that's just values
I don't like set + map-of because it makes explanations less clear
It might be better to coerce the keys in a separate step
@lopalghost more importantly it breaks link between key and value
Right
so yeah either coercion, or it might be better to just have a custom predicate to validate such maps
you can use every
on maps to describe the map entries as k-v tuples
like (s/every (s/or :name-entry (s/tuple #{”name”} string?) :id-entry (s/tuple #{”id”} int?)) :kind map? :into {})
but whatever or’ed entry types you need
for non-kw key maps, this can be a good approach
(that’s how every-kv
and ultimately map-of
are actually implemented)
I think I saw it being discussed here a few weeks ago, and I though “who would ever want to do that?” Turns out I am someone who would want to do that.