Fork me on GitHub
#clojure-spec
<
2018-08-27
>
misha05:08:23

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}

ikitommi09:08:52

the result doesn’t conform anymore to the spec.

alexmiller11:08:22

that’s often true regardless

misha12:08:28

@alexmiller have you considered doing this (qualify keys) as part of s/keys or s/conform behavior?

alexmiller12:08:08

I am confused by your question

misha12:08:08

opieop will such qualify be a part of clojure.spec someday? if "definitely not", why?

eoliphant20:08:33

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

misha21:08:44

you might keep context in an atom, and access it inside of your predicate

eoliphant23:08:47

yeah i'd been thinking about that, but it feels weird lol. I'd really like to have the context scoped down to what's going on at that time, but I may give that a whirl to start