This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-06
Channels
- # announcements (1)
- # bangalore-clj (3)
- # beginners (73)
- # boot (1)
- # calva (88)
- # cljdoc (13)
- # cljsrn (1)
- # clojure (65)
- # clojure-finland (1)
- # clojure-spec (14)
- # clojure-uk (1)
- # clojurescript (50)
- # core-async (4)
- # datavis (6)
- # duct (2)
- # figwheel-main (1)
- # off-topic (15)
- # pedestal (16)
- # planck (11)
- # re-frame (3)
- # shadow-cljs (19)
- # yada (3)
set!
in that context, used as a past tense verb, is pronounced "set-bung"
Is there a way to construct the selection in s/select
programmatically? e.g. have the selection somewhere as data (in db, edn, etc) and make a select out of it at runtime.
also, could the selection syntax allow something special that effects the whole keyset, not present an individual key. Could be just a function or a special Protocol.
(s/def ::passwords-must-equal #(= (:password1 %) (:password2 %)))
(s/select ::user [::user ::password1 ::password2 ::passwords-must-equal])
;; or
(s/select ::user [::user ::password1 ::password2 #(= (:password1 %) (:password2 %))])
… if that special keyset-validator would be implemented with a protocol, it would be great to have a function which takes both the spec
and the value
as arguments, so one could easily write something like ::closed-keyset
: the function could extract the list of defined keys from the spec
argument and use that to verify that the value
doesn’t have any extra keys. And if the validation could return the ::s/problems
instead of just ::s/invalid
, it would be easy to write those, e.g. no need to write separate explain too.
+1, would be nice to have something like that. because currently relying on forms, macros or low-level *-impl
helpers is quite cumbersome (e.g. see my attempt at implementing merge-able closed keys spec with user-friendly explain here: https://groups.google.com/d/msg/clojure/duY3ojPwPYo/Wgvk9PsaCAAJ)
I too have almost mergeable closed specs with Spec1, but next hurdle is to get deep-mergeable specs...
You have two routes to programmable specs in spec 2
You can make forms, and call spec*
Or you can make your own syntax that wraps something with defop
Or actually third option is making your own spec instance from scratch but that’s a much heavier lift
We are evaluating support for preds in specs - tbd
But we are working on another kind of checking for closed specs
Sorry, gotta run