Fork me on GitHub
#clojure-spec
<
2018-11-30
>
benzap13:11:34

So Rich said they're releasing a new clojure.spec, is it going to be radically different, or backwards compatible?

mpenet14:11:51

he mentioned being careful about backward compat in the talk. Then again it's an alpha, so breakage might very well happen

alexmiller14:11:28

The plan is that it will be as backwards-compatible as possible

alexmiller14:11:58

Things like s/keys may continue to exist but be deprecated for example

gklijs14:11:19

From what I got, instead of having to split into required and optional argument sin the spec. it's moved to something different, and you can specify on the function witch fields you need/expect

gklijs14:11:29

It it already in spec alpha-2, or do we need to wait a bit?

alexmiller14:11:31

No, it’s not available yet

alexmiller14:11:08

We are doing some reorg of the impl in spec-alpha2 at the moment

alexmiller14:11:31

And then we will be diving into the new stuff

benzap14:11:24

just finishing up the talk, so spec stuff will be baked into defn, or is that pseudo-code?

benzap14:11:40

or rather spec/defn

benzap14:11:31

man, i'm really excited for these changes

benzap14:11:18

I was hesitant when using spec in my work's project, but I feel like it would really benefit from these changes, especially when defining specs between different data layers

orestis15:11:11

Just a few days ago I suggested to someone to just use optional keys for his specs and validate presence of keys in some other way. (GraphQL context). Glad to hear there’s going to be a better way.

🙂 8
alexmiller16:11:29

@benzap it’s possible it will get integrated more into defn - currently TBD but Rich is thinking about it

benzap16:11:39

Interesting! I can definitely see the tradeoffs on both sides

alexmiller16:11:05

that of course wouldn’t happen till Clojure 1.11, if at all

benzap16:11:32

That's good to know, i'm thinking i'll use the current clojure.spec until then