Fork me on GitHub
#clojure-uk
<
2018-12-02
>
yogidevbear09:12:39

Morning 🌄 To everyone going to the ClojureX pre conference workshops today, have fun ❤️

waving 8
paulspencerwilliams09:12:03

I’d have loved to attend but travel was just too tricky.

yogidevbear13:12:41

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 🙂

3Jane13:12:59

^ good guy

flefik10:12:45

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/schema and 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?

rickmoynihan22:12:46

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 s/or and :req/:opt. :req/:opt` are options to s/keys not 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/select with 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 s/select. 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.

rickmoynihan22:12:49

Anyway I could be wrong about all of this, we’ve not seen any definitions yet.

rickmoynihan22:12:02

But I hope you find it useful.

flefik08:12:49

I do, thanks!

👍 4
folcon11:12:36

Morning :)…

yogidevbear14:12:17

@lady3janepl @thomas are you both at the sessions today? How was/is the Kafka session?

thomas14:12:53

we are, and the kafka session was good. A nice intro to kafka.

thomas14:12:59

Now we are doing Spec

3Jane14:12:55

yeah, I thought Kafka was very good at demystifying the whole subject

yogidevbear14:12:58

Someone will have to tell me about it tomorrow/Tuesday 🙂

thomas14:12:49

sure... just come to us.... we'll tell you all we know. should take only a few minutes 😉

😂 8
seancorfield18:12:54

@cfeckardt yes, separating the possible shape (schema definition) from the actual required data elements at point of use (select) is the key aspect of the solution. Decomplects the two things that s/keys currently does.