This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-02
Channels
- # beginners (118)
- # boot (73)
- # cider (2)
- # cljs-dev (65)
- # cljsrn (18)
- # clojure (49)
- # clojure-argentina (4)
- # clojure-italy (19)
- # clojure-portugal (1)
- # clojure-russia (1)
- # clojure-spec (34)
- # clojure-uk (102)
- # clojurescript (202)
- # code-reviews (3)
- # core-async (5)
- # cursive (11)
- # datomic (25)
- # emacs (1)
- # graphql (22)
- # hoplon (6)
- # keechma (59)
- # leiningen (10)
- # luminus (31)
- # lumo (78)
- # off-topic (141)
- # om (32)
- # om-next (2)
- # onyx (6)
- # parinfer (55)
- # pedestal (3)
- # protorepl (3)
- # re-frame (8)
- # reagent (8)
- # ring-swagger (1)
- # rum (20)
- # specter (1)
- # sql (5)
- # test-check (11)
- # vim (13)
- # yada (7)
Could someone help me understand why for the given example fn
(defn my-fn [selector]
(condp = selector
1 :b
2 :c
false))
it fails on the :ret
spec when calling the fn with the following spec
(s/fdef my-fn
:args (s/cat :selector any?)
:ret #{false :b :c})
but not for the following spec
(s/fdef my-fn
:args (s/cat :selector any?)
:ret (s/or :a #(= % false)
:b #(= % :b)
:c #(= % :c)))
prolly comes down to this: (s/valid? #{false 😛 :c} false) -> false or (#{false} false)
-> false
Is there some established/idiomatic way to use spec with core.async? Particularly when reading from a channel?
Or would it come down to adding a spec to a function that pushes on to the channel you are reading from?
@camdez thanks for last week's answer about clojure.spec.alpha/invalid
in the context of spec's code stability 🙂
@camdez will I bump into a lot of stuff coming from its "alpha" namespace when using spec today?
Am I correct in thinking that spec would be the wrong tool to assert relationships between keys in a map.
For example, lets say we're representing a bill split between n
folks, can/should you leverage spec to assert that the sum of amounts under the payees key is greater than or equal to the top-level amount?
If not spec, is there some other library that allows you to organize validations like these in a way that lends support to generating good error messages
{:amount 60
:payees [{:name :andy
:amount 20}
{:name :rich
:amount 20}
{:name :alex
:amount 20}]}
then it's just pattern matching on the explain to return something more "flat" for error messages (depending on your usage), which you can do with/without spec (you could build it with a spec errors conformer that maps to your precise error types)
@cddr https://github.com/xsc/invariant this looks better for that
on the contrary, I really don't think you need a library to describe a datastructure -- this is literally the rationale for clojure.spec
you're trying to define an invariant about a data structure, not a contract. I like the idea of separating those concepts (thus using a library to define invariants looks like a good idea)
but yeah, that's just being pedantic, so for a simple structure like this, I agree adding a new dependency is probably an overkill
I definitely prefer using the standard lib when it supports what I'm trying to do. Cheers for the suggestion though. Looks interesting 🙂
I think invariant is just a library for defining data structure predicates. if you have to write enough/complicated enough data structure predicates I think it would be useful to use with spec. similar to how specter is useful if you've got to do enough deeply nested data manipulation
@cddr yeah, it is! I'm probably biased towards it because I used it and liked it a lot hahaha. In my case, I had to define invariants on a custom markup language
is it possible to define a spec for map keys without def
ing a separate spec for each key? I guess what I have in my head is something like:
(s/keys :req-lit {:first-name string?
:last-name string?
:email (s/and string?
#(re-matches email-regex %))})
...where you could spec map keys inline?I think that's an intentionally excluded feature
https://clojure.org/about/spec - “Map specs should be of keysets only”