Hm, I don’t really understand how to use retag

I mean, I can use it with a keyword, but now I have something a bit more complex: a schema is either a reference (`{:$ref “some-string"}`) or a schema with a type

I was hoping to teach the multimethod about that, since s/or doesn’t seem to work

(when I s/or, it complains that it can’t find an appropriate method, which is true I guess; I wasn’t expecting it to even try that branch)

I tried doing with with s/or this way:

(s/def ::schema
  (s/or ::reference
        (fn [m] (contains? m :$ref))
        ::direct-schema
        (fn [m] (contains? m :type))))

Which doesn’t work because spec doesn’t know how to generate schemas from that pred.

I can (s/and map? …) but that doesn’t really make it easier to generate maps

I guess I can just use map? and it can later specify with keys — that appears to sorta work 🙂

(s/def ::$ref uuid?)
(s/def ::type keyword?)
(s/def ::schema (s/or ::reference (s/keys :req-un [::$ref]) ::direct-schema (s/keys :req-un [::type])))

@lvh: I think you are supposed to do it in the style above.

Hello. Is it possible to assert properties about keys and values in a map using s/keys without using the registry?

Not that I know of.

@michaeldrogalis: You can put keys into s/keys that aren't in the registry, and the spec will just check for their existence. It is not possible to provide inline specs to validate map values.

@codonnell: Thanks for the confirmation.

no problem

http://blog.cognitect.com/blog/2016/7/26/clojure-spec-screencast-testing

new screencast about check and instrument

Awesome, thank you!

@alexmiller Neato 🙂

Are there any thoughts on using spec for something like web form validation? Specifically having some way to generate user-readable messages from failed predicates, i.e. more fine-grained than "Name is wrong"

(I don't have much experience with spec, apologies if this is either a really frequent question or a really stupid one.)

@jonathanj: IMO, the output would be okay for parsing for a web form. However, spec doesn't play too well with cross validation, e.g. "is this email taken in the database?"

I also found specifying equal fields difficult, with meaningful output, so you'd have a few special cases to handle outside of s/keys

Are you referring to the error data when you say output, @dominicm? I don't see how the error data would be suitable for a user-facing form, you need a layer of translation since arbitrary predicate names are unlikely to be of value to users in most circumstances.

My apologies, suitable for translating to user information.

@dominicm: what about involving multiple values in a validation? We have a case where the SSN needs to be validated against the gender of the selected title (don't ask), would this be written as a separate spec that combines the others, with and perhaps?

And perhaps more interestingly, would the error data allow me to determine all the participants in the failing validation?

User forms have plenty of awkward cases, domain logic runs rampant here. I think and would be appropriate yes. You want to ensure the SSN, gender and selected title are all valid before doing the overall validation I assume? That would be s/and. I don't know the api too well though, my interest dwindled when I tried to use spec for web forms and found limitations in spec.

I did find that the output error data was very thorough though, and you could derive a lot of information from it.

@dominicm: You're quite right about awkward cases for user forms, did you go another route in the end?

I started writing my own validation library.

Is the code public?

Not yet 😞

I should open source my attempts.

https://github.com/logaan/vlad I can highly recommend vlad though.

I've already written two (JS) validation libraries and they are plagued with reinventing existing predicates. I was hoping to find a better way of layering this on something else.

vlad has a lot of useful predicates built in. https://github.com/weavejester/valip/blob/master/src/valip/predicates.clj I sometimes take advantage.

My experience was that a Boolean is not a good enough result for explaining errors to users, but having to decompose the data after the predicate failed was too much duplication of effort

Nope, you must attach additional semantics to it. That's where vlad comes in.

I just realised that the README does not do it justice.

https://github.com/logaan/vlad/blob/master/src/vlad/core.cljc#L117 this is the definition of the present? checker

Skimming the readme, vlad seems worth further investigation, thanks!

@dominicm: Nice, reasonably succinct.

It's the result of much comparison, I'm glad you can benefit from my research 🙂

does anyone know what this error means?

https://gist.github.com/bsima/042554a1a61ce18adad0ebaae60a833f

@bsima: Which version of Clojure? That works for me on Alpha 10.

1.9-alpha10

¯\(ツ)/¯

I think a lein clean fixed it

lein clean solves so many evils 😈

@gfredericks: Just following up real quick on that issue last week where explicit loading of test.check and clojure.spec.test/check lead to MultiFn errors. You mentioned master seemed to fix it. Any thoughts on when the next release will be cut?

Probably depends on whether it's still painful for @alexmiller

It is

@dominicm: interesting, didn't know about vlad, looks cool

@kendall.buchanan: I'll prioritize getting a good release together ASAP

@gfredericks: Thank you. I don’t mean to put pressure on you, or anything, but I do sure appreciate it.

No worries

I’m willing to do a release, just would prefer to do as few as possible as it will take me at least an hour to figure out how again

@gfredericks: a good change log wrt to things likely to affect spec would also be helpful to have

@alexmiller: like to send to you folks or for permanent public consumption?

public, not looking for anything special for us, just to have a place to start analyzing impact

Cool