This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (286)
- # aws (3)
- # beginners (243)
- # calva (4)
- # cider (51)
- # cljs-dev (8)
- # clojure (74)
- # clojure-conj (1)
- # clojure-france (1)
- # clojure-italy (1)
- # clojure-spec (21)
- # clojure-uk (22)
- # clojurescript (25)
- # clojurex (6)
- # code-reviews (5)
- # core-async (3)
- # cursive (1)
- # defnpodcast (1)
- # fulcro (29)
- # mount (1)
- # off-topic (85)
- # onyx (5)
- # other-languages (7)
- # pathom (6)
- # pedestal (6)
- # re-frame (20)
- # reagent (2)
- # reitit (8)
- # ring-swagger (10)
- # shadow-cljs (53)
- # spacemacs (8)
- # tools-deps (34)
Morning 🌄 To everyone going to the ClojureX pre conference workshops today, have fun ❤️
I had a spot, but couldn't make it. I replied as not going on Friday night and there was one person on the waiting list. 10 minutes later I checked and they were listed as going. Felt like something good came out of my misfortune 🙂
I rewatched the talk and I think my misunderstanding boils down to this statement by Rich in the talk: "It's a mistake to put optionality in aggregate definitions"
So I guess the difference between:
(s/or (s/select a) (s/select b)) and
(s/spec :req/:opt) is that in the former case you have either set a, or set b, but in the latter case you have the some
:opt keys, but no information given about which of these arguments need to be provided together in order for the parameter/ret value to be valid. Additionally there is no natural coupling between different method calls of the same 'base' type when using :req/:opt, where as when you split
s/select you get that nice schema reuse?
So to use the nomenclature of the talk
s/schema represents the shape of the collection you're passing, or rather what it can contain. And
s/select are the keys in that type that are required for this method call. Optional arguments are left out and
s/or is reserved for cases like
(s/or (s/select a) (s/select b)). Does that sound right?
When you wrote this:
> So to use the nomenclature of the talk
s/schema represents the shape of the collection you’re passing, or rather what it can contain. And
s/select are the keys in that type that are required for this method call.
Then yes, it sounds like you’ve got the gist of it yes.
However Rich said nothing about doing
(s/or (s/select a) (s/select b)). And it seems like you might be misunderstanding the use of
:req/:opt` are options to
s/spec. And Rich said nothing about
s/or... And I’d assume that
s/or will remain as is, as it’s pretty essential in writing the “RDF attribute-like specs” he mentions, and combining arbitrary specs together.
At this stage I wouldn’t think of using
s/or at all... Instead think of attaching an
s/select annotation to each function definition that uses a subset of the schema. Each function can then specify it requires or guarantees a different subset of the schema with
I’d imagine it makes sense for an
s/select to be a spec also, in which case you should be able to use them with
s/or too; however as far as I can see that was not the point of this talk at all.
The other thing Rich hints at as being mistaken is saying
(s/def ::postcode (s/nilable string?)... as this is essentially a
Maybe. He’d rather the nilableness was moved to the edge/context rather than baked into the attribute spec itself. I suspect this usage will still be allowed but discouraged in idiomatic code.
sure... just come to us.... we'll tell you all we know. should take only a few minutes 😉