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:
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.
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 😬
is it schema
? or maybe I’m thinking about select
— I should just review the docs :face_with_rolling_eyes: sorry
schema
defines the possible set of keys. select
defines the required subset of a schema.
Hence, decomplecting specifying requiredness from specifying possible 🙂
Sounds pretty exciting, honestly!
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”
Yup, I'm looking forward to Spec2 becoming non-alpha and the "standard" way to work with Spec.
1👍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👍