This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-21
Channels
- # beginners (201)
- # boot (125)
- # cider (3)
- # cljs-dev (21)
- # cljsrn (165)
- # clojars (8)
- # clojure (332)
- # clojure-belgium (1)
- # clojure-gamedev (8)
- # clojure-russia (75)
- # clojure-spec (25)
- # clojure-uk (96)
- # clojurebridge (2)
- # clojurescript (130)
- # code-reviews (16)
- # cursive (26)
- # datomic (20)
- # devops (6)
- # emacs (6)
- # hoplon (90)
- # jobs (9)
- # luminus (2)
- # off-topic (4)
- # om (65)
- # onyx (5)
- # pedestal (4)
- # protorepl (6)
- # re-frame (34)
- # reagent (12)
- # ring (4)
- # ring-swagger (7)
- # specter (2)
- # test-check (8)
- # untangled (2)
- # vim (1)
- # yada (6)
maybe you could use the funcool "cats" library to handle side effects, and check for right
/`left` return types in the spec? idk, haven't used it much
using conformer
, wondering how to conform a given input efficiently without conforming then unforming
@jiangts Can you give an example or elaborate your problem some more? I don't see why you'd need to conform and unform using conformer
@dergutemoritz when you coerce with just conform
you get a parsed version of the data, including the paths on or
s or keys
for example. I’d like a coerced version of the data without those key paths, which can be removed with unform
Ah, I see
There are multiple ways around that. For example, in case of s/or
, something like this will do: (s/and (s/or ...) (s/conformer val))
For s/cat
, often if you don't care about the path labels, you are probably looking for s/tuple
instead
But perhaps you should think about whether keeping the path labels is actually the better idea!
does it make sense to have a separate file for general specs and then inline specs that are specific to that namespace?
@ag (gen/let [gen'd-accounts (-> :account/spec s/gen (gen/vector (count accounts)))] (map merge gen'd-accounts accounts))
@gfredericks hmmm, mkay
Has anyone written a destructuring to spec translator? Idle thought really. I was wondering about how to spec namespaces with less overhead... a convention based around arglist destructuring and using variable names which match registered specs could work. e.g.
(s/def ::base-url string?)
(s/def ::request (s/keys :req-un [::url ::params]))
(s/def ::page-limit pos-int?)
(s/def ::page-count pos-int?)
(x/defn load-options
[{:keys [base-url]} [_ request page-limit page-count]]
...
Also, merry xmas everyone.
I guess the same could be done after the fact by referring to the fn :arglists metadata.
Noted here for posterity: https://gist.github.com/olivergeorge/85c2b263227676324275ce13408c0fb8
Feel free to comment there if it's a terrible idea or I'm missing key points.
for perf reasons, we would not do that in core
is there a way to write an fdef
that says "this function should take :my/spec
as it's argument but only after the arg has conformed with (conform :my/spec arg)
" ??
@alexmiller that sounds sensible. hard to imagine it being unopinionated enough to be suitable as a core feature too. Do you think the idea has merit? I guess the real benefit is tidier code which is superficial.
@alexmiller there was talk of a "dev version" of clojure with more spec integration... less performant but more errors for the developer. Is that still on the cards?
@olivergeorge: seems like most cases that's not what I would want
On the dev version, possibly although just not front burner right now