This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # boot (24)
- # cider (8)
- # cljsjs (1)
- # cljsrn (5)
- # clojure (22)
- # clojure-greece (1)
- # clojure-italy (3)
- # clojure-russia (218)
- # clojure-spec (33)
- # clojurescript (51)
- # core-async (6)
- # cursive (1)
- # datomic (13)
- # defnpodcast (2)
- # funcool (2)
- # lein-figwheel (21)
- # onyx (41)
- # proto-repl (4)
- # protorepl (5)
- # reagent (4)
I think so
Yes to some degree. I went through and wrote most of them at one point but things have drifted. However, we explicitly don't check macro fdefs in spec as that will cause an infinite loop.
So they may exist mostly as documentation
the uncheckable macro?
I expect the same reason most of the spec definers is a macro
I don’t know what that reason is (I just know that it’s annoying when I’m dynamically defining specs and it’s complaining that
(some expr) isn’t a bunch of namespaced keywords)
"Yes, this means that more of the surface area of clojure.spec will be macros, but specs are overwhelmingly written by people and, when composed, manually so."
why're you generating your specs
why not go the other direction?
it’s other people’s json schema, for other services; also json-schema for swagger, which I in turn use to generate specs for even more third party stuff
unfortunately it’s unlikely that I get all of these vendors to port their swagger specs to clojure.spec 😄
yes they want to see the exact expression
so you probably have to think of it more as a pre-compile step
I’d like to have the specs available easily as a map, because since it’s autogenerated there’s a pretty good chance that you’ll want to amend the result
(defmacro load-specs  (code to make spec forms)) (load-specs)
if you want to really wash your hands of dynamic runtime monkeydoodling you could generate the code and spit it to a source file that goes into version control
so it turns into a dev-time task