Looks neat, I see there is "Coercion overrides map to specify contextual coercions" on the TODOs, will that let you specify different contexts like a JSON payload or form encoding, e.t.c.?

@danielcompton thanks for the interest 🙂 for that I was thinking more like when you do generator overrides, like you do on specs, I think the main use case would be to set a custom parser for a different date/time format depending on the source

hey, is there a way to and additional predicates onto existing keywords when used in spec/keys for a new def?

e.g. i have :db/id which can be any int? but when i have a :db/id in a (spec/def :item/new ...) i also want to ensure that it is the specific int -1

No, but you can s/and additional constraints over the s/keys

@alexmiller like this?

(spec/def ::item
 (spec/and
  (spec/keys :req [:db/id])
  (comp #(spec/valid? ::id %) :db/id)))

that's a little different to what i asked

(spec/def ::id
 (spec/or
  ::id--new #{new-item-id}
  ::id--existing pos-int?))

but seems to be what i want when i run exercise, thanks 🙂

I would try to avoid the comp valid? … and instead state it as an additional spec or predicate

you can also use s/merge instead of s/and to combine two map specs together

one general, and one more specific

s/keys already checks that the value for the key conforms to the spec, so the extra check in your ::item is duplicating that

@alexmiller ah, i'm pretty new to this, could you give me a simple example of that?

(spec/def :db/id int?) this is :db/id

so that's any int

but the item id has to be either a positive int or new-item-id (which is -1)

it can't be just any negative int

I think you mostly have it above already

your ::id looks good

and then just (spec/def ::item (spec/keys :req [::id])) is sufficient

spec/keys checks that the map has the required keys and that every registered key spec has a value that conforms to that spec

except that when i do exercise it generates maps with ::id instead of :db/id

i can't actually pass it ::id because the key :db/id is coming from upstream

so, related question

sorry, it was unclear whether those were the same or different things

oh well yeah

i've got something related

i have a :project/id

and i want to reference it with :item/project

they have the same predicate so i thought i could do (spec/def :item/project :project/id)

but it doesn't like that

should work fine - what’s not working?

Unable to resolve spec: :project/id

could you give a larger example that produces that?

hmm

so

(spec/def :project/id uuid?)
(spec/def :item/project :project/id)

works

but when :project/id is in a different ns (that i required) it gives the error

can you give that example?

there is a known issue right now with ordering of something like that such that the aliased spec needs to be defined first

are you running into something like that?

potentially

i'm stopping and starting my test runner now

maybe it got confused with me changing things

https://dev.clojure.org/jira/browse/CLJ-2067

yeah it seems fine now

so i cannot reproduce

weird

probably an ordering issue

I’m taking off! Later…

thanks for the help!

ok @alexmiller, added the current changes as a patch too if that helps the conversation with Rich.