Clojurians Log v2

I really like how succinct spec-tools data-specs are. It takes 17 lines worth of specs for a map that has a key that has a collection of maps down to 3 lines. Will Spec2 be able to do this as well? The syntax described here https://github.com/clojure/spec-alpha2/wiki/Schema-and-select#unqualified-keys looks quite similar. The description makes it sound like that syntax will only be available for unqualified keys though.

That’s correct

Why not support qualified keys with that syntax?

(s/def ::error-code string?)

(s/def ::error-message string?)

(s/def ::id uuid?)

(s/def ::failed-request
  (s/keys :req [::error-code ::error-message ::id]))

(s/def ::failed-requests
  (s/coll-of ::failed-request))

(s/def ::result
  (s/keys :req [::failed-requests]))

(s/def ::result
  {::failed-requests [{::error-code    string?
                       ::error-message string?
                       ::id            uuid?}]})

https://clojure.org/about/spec#_global_namespaced_names_are_more_important

Sorry, I don't follow. The latter could easily expand to do exactly as that doc describes.

the objective here is not just to validate but to build a library of reusable (ie named + registered) specifications

Well, I suppose the nested map wouldn't have a name.

@alexmiller heya, if you're around can I ping you about https://clojurians.slack.com/archives/C1B1BB2Q3/p1579620754050400?

what do you mean by 0.1.x and 0.2.x?

are you talking specifically about spec.alpha?

https://github.com/clojure/spec.alpha/blob/master/CHANGES.md

0.1.x is Clojure 1.9 era and 0.2.x is Clojure 1.10 era

I don't think there were any breaking changes between those

So Spec1 forces you to do that with unqualified keys. Why has that changed with Spec2?

yes that is what I meant

not sure I understand the question

trying to update from cljs 1.10.520 to `1.10.597` causes my app to have a runtime error for optimized builds on what seems to be something spec related, so I thought there might be a breaking change

what are 1.10.520 and 1.10.597 applicable to?

If I'm understanding the syntax here https://github.com/clojure/spec-alpha2/wiki/Schema-and-select#unqualified-keys, you are no longer creating a reusable specification for the nested map.

oh cljs, sorry that got lost

spec.alpha is CLJ only

the cljs spec impl is inside ClojureScript so the stuff above does not directly correlate

ah I see... so maybe I should ask about cljs.spec.alpha in #clojurescript instead

Well, that I guess that applies for key & value in that ::order spec. Nothing is reusable.

well, you are in the schema, but not in the sub levels. as unqualified names, they often are ambiguous

you still can do like you did in spec 1 (relate unqualified keys to qualified specs) but it's not constrained to the unqualified name match and it's optional

yeah

I don't know anything on that

coolio, thanks for the direction!

To be clear, the issue with something like this

(s/def ::result
  {::failed-requests [{::error-code    string?
                       ::error-message string?
                       ::id            uuid?}]})

you're inventing syntax here, it can't be just considered in isolation

Fair enough. I mean like this

(s/def ::order 
  (s/schema {:purchaser string? 
             :due-date inst?
             :line-items (s/coll-of (s/schema {:item-id pos-int? 
                                               :quantity nat-int?})
                           :kind vector?
                           :min-count 1
                           :gen-max 3)}))

this now occupies the "map" slot in the language of specs, which may have other uses

certainly, this goes against the grain of naming and registering the specifications. names have multiple utility in spec - they are used for spec reuse, but also in things like explain reporting, and I don't remember what else

none of this rules out the possibility of adding more support for concise definition of multiple specs in tandem

or even extension to support this in the future, but it's not our top concern

and if we were going to do so, it would be driven by a top level problem, not just "it's a thing we can do".

Understood. I don't think it necessarily goes "against the grain of naming and registering".

(s/def ::order
  (s/schema {::purchaser  string?
             ::due-date   inst?}))