Clojurians Log v2

Yeah, that's what we've ended up doing. Ta 🙂

in spec-alpha-2, will selects be composable? Assuming the answer is "yes," what does that look like?

I think the answer will be no, actually, but it depends what you mean. which part are you looking to compose?

Personally, on the frontend the concept of static views that can define a select from the global state of the UI, then combining all of these into a single one for the whole of the UI?

We have a data structure that is going to accumulate keys as it moves through our system. To model that, it would make sense to have a selection for "phase 1," then a "phase 2" that takes phase 1 and adds a few keys, and a phase 3 that builds on phase 2, and so on. It would be nice to keep that DRY. (Actually we have a data model DSL that generates our specs, so we could always do the composition at that layer, but I wanted to know what spec-2 was planning on supporting.)

I guess I should've phrased my question as "are selections mergeable"

I think that's a very interesting and unresolved question

it depends somewhat on whether you see merge as an operation that produces an intersectional spec or whether it acts as parallel filters through which a value must pass (which is closer to how it's implemented)

Wouldn't the first option be better for generation?

certainly the latter seems doable

are the args to select dynamic, i.e. can you merge those programmatically?

for generation, this is not that different than s/and in that you need to generate something that "passes" both specs but it's probably more challenging here

I remember having serious issues with json-schema based validation because json-schema can be async, that is remotely resolved, and circular

in spec 2, all of the spec can be passed as data which makes it amenable to merging the specification as data

So merging there was only possible with serious limitations and strict conventions

there are a couple different ways data-based specs can be created in spec 2, so you actually have several choices - custom ops with s/defop (think spec template with holes), symbolic forms as data, and specs represented as maps. all of those are implemented now (with some caveats that the map form is kind of a hack in a few spots that are likely to change)

I was wondering if selection merging would be a first-class feature, but it sounds like I'll probably want to do the composition at the data model DSL layer. That will generate our specs, schemas, and selections. The implementation will be a lot cleaner with spec 2.