This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-25
Channels
- # beginners (20)
- # boot (25)
- # cider (1)
- # cljs-dev (7)
- # cljsjs (1)
- # cljsrn (1)
- # clojure (79)
- # clojure-austin (2)
- # clojure-berlin (13)
- # clojure-dusseldorf (1)
- # clojure-germany (7)
- # clojure-russia (10)
- # clojure-serbia (1)
- # clojure-spec (18)
- # clojure-uk (4)
- # clojured (1)
- # clojurescript (90)
- # cursive (10)
- # datomic (7)
- # emacs (14)
- # hoplon (6)
- # luminus (16)
- # lumo (4)
- # numerical-computing (2)
- # om (25)
- # om-next (1)
- # onyx (11)
- # pedestal (10)
- # protorepl (1)
- # reagent (11)
- # remote-jobs (1)
- # ring (1)
- # rum (38)
- # spacemacs (5)
- # test-check (7)
- # untangled (122)
- # vim (1)
- # yada (8)
I know this question has been asked before (a few months ago), but we're a few months later now: are there any plans/projects using clojure.spec instead of prismatic/scheme in yada?
For parameter validation?
Right.
prismatic/scheme works pretty well, but I'd prefer clojure.spec these days. Well, clojure 1.9 is not released yet, so I fully understand yada is not switching (yet). I just wonder if there are any plans or projects busy replacing prismatic/scheme with clojure.spec .
@kurt-yagram I think there are still some limitations of specs that need exploring before it can be fully utilized. There are some contentions, for example: spec believes you should accept all keys, even extraneous. This goes against expectations for forms though. So yada needs to figure out a default here. The refactoring in 1.2 did a lot to split up the codebase. Schema is still quite entwined in the resource model of core yada though. I expect spec will eventually land. But it's not a feature being developed right now.
allright, thanks! It's good to know...
I wonder if yada takes a function where it takes a schema? That might be a useful way to wrap up specs now. I'll probably investigate that tomorrow.
https://github.com/juxt/yada/blob/master/src/yada/parameters.clj Is based on the schema protocols, if you wrote a function to put a spec inside a protocol, it may just work... Though I think a function override would be better in all cases. Alternatively: rewrite the interceptor chain. Can't decide which is a better solution really.