This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-27
Channels
- # bangalore-clj (1)
- # beginners (187)
- # braveandtrue (52)
- # calva (7)
- # cider (17)
- # cljs-dev (14)
- # clojure (27)
- # clojure-austin (4)
- # clojure-dev (11)
- # clojure-finland (4)
- # clojure-italy (5)
- # clojure-nl (1)
- # clojure-russia (22)
- # clojure-spec (9)
- # clojure-uk (27)
- # clojurescript (91)
- # datomic (40)
- # duct (4)
- # emacs (14)
- # figwheel-main (36)
- # fulcro (11)
- # hoplon (10)
- # immutant (9)
- # instaparse (4)
- # java (1)
- # jobs (2)
- # off-topic (28)
- # pedestal (1)
- # reagent (15)
- # reitit (7)
- # remote-jobs (6)
- # ring-swagger (3)
- # shadow-cljs (28)
- # slack-help (1)
- # spacemacs (4)
- # specter (1)
- # sql (3)
- # testing (3)
- # tools-deps (24)
is there any downside in "conforming unqualified maps into qualified ones"? e.g.
(qualify
(s/keys :req-un [:foo/bar])
{:bar 1})
=>
{:foo/bar 1}
that’s often true regardless
@alexmiller have you considered doing this (qualify keys) as part of s/keys or s/conform behavior?
I am confused by your question
hi, quick question. what's the best way to handle getting 'context' into spec functions (or is this even a good idea?) For instance, I'm playing around with a little data-driven schema definition tool, and I want an attribute type to be either one of a set of primitive types, or another type defined in the schema. so I want to do something like (s/or ::attribute-type #{:type1 :type2} (fn [val] (is-val-in-list val external-list))
. where external-list
might have been setup right before a call to s/valid?, etc