clojure-spec

About: http://clojure.org/about/spec Guide: http://clojure.org/guides/spec API: https://clojure.github.io/spec.alpha/clojure.spec.alpha-api.html
kenny 2020-01-08T00:19:40.024700Z

Has anyone written a version of spec2 select that works with spec1? Deciding to have keys required or optional for all use cases is so painful 😣

seancorfield 2020-01-08T00:45:20.025600Z

@kenny Not sure what you mean by "works with spec1"? The two libraries use different registries so you cannot combine them (at least, not easily)

kenny 2020-01-08T00:45:47.026100Z

I mean a macro for spec1 that imitates spec2's select.

kenny 2020-01-08T00:47:02.027500Z

When using nested maps, spec1 doesn't let you change which keys in the nested map are required.

seancorfield 2020-01-08T00:47:05.027600Z

That's exactly why Spec2 is coming -- that required/optional thing in Spec1 is painful 🙂

seancorfield 2020-01-08T00:47:58.029Z

In Spec1 that is complected and baked into how s/keys works. In Spec2 the set of keys and the requiredness are decomplected.

avi 2020-01-13T16:31:06.038400Z

You know, it just occurred to me — this is going to make it hard to create an interop schema using spec — in other words, to fully describe a data structure that a system expects/requires, including the keys that are required in each map… I suppose we might need to write some new plumbing to create a schema based on some spec2 specs, with additional annotation, expectations, etc. :thinking_face:

seancorfield 2020-01-13T16:49:44.040Z

I'm not sure I follow. Spec 2 still let's you specify which keys are required, including nested keys. It just teases the two concepts apart.

avi 2020-01-13T17:20:01.040200Z

Hmm for some reason I was thinking that the new schema function was designed solely for the case of defining function specs… but I haven’t looked super closely 😬

avi 2020-01-13T17:20:42.040400Z

is it schema? or maybe I’m thinking about select — I should just review the docs :face_with_rolling_eyes: sorry

seancorfield 2020-01-13T17:43:47.040600Z

schema defines the possible set of keys. select defines the required subset of a schema.

seancorfield 2020-01-13T17:44:29.040800Z

Hence, decomplecting specifying requiredness from specifying possible 🙂

avi 2020-01-13T17:44:56.041Z

Sounds pretty exciting, honestly!

avi 2020-01-13T17:45:46.041200Z

I just did a walkthrough of a pretty involved schema using spec1 with some members of my team who aren’t familiar with it, and they asked a bunch of questions that I answered with “not right now, but that’s coming in spec2”

seancorfield 2020-01-13T18:10:39.041400Z

Yup, I'm looking forward to Spec2 becoming non-alpha and the "standard" way to work with Spec.

👍 1
seancorfield 2020-01-13T18:12:22.041600Z

For a while, I had a branch at work tracking Spec2 but with the number of bugs and changes as it has evolved, it was proving a bit much trying to keep our codebase current on it... so I gave up a while back and we'll take another look once it is stable. I doubt we'll migrate, but we'll probably start using Spec2 for new code (and may convert old code over as we maintain it over time).

👍 1
kenny 2020-01-08T00:48:27.029500Z

Ya. Was hoping for a workaround for now. It seems potentially possible to get it to work.

seancorfield 2020-01-08T00:49:49.030500Z

I don't know if s/merge will let you override an all-optional s/keys with a subset of keys that are now marked required. Doesn't help you much with nesting I suspect.

seancorfield 2020-01-08T00:50:31.031100Z

You could just start using Spec2 I suppose 🙂 But not for any production work as it's still changing a lot.

kenny 2020-01-08T00:53:25.032900Z

It's gotta be production worthy unfortunately