here is an example: https://gist.github.com/eyston/c797efc5e4c07304e0c331b97decd107 — was doing the first thing and its opaque, tried the second way after reading http://thegeez.net/2016/12/09/parsing_clojure_spec_advent_of_code.html

unsure if good / bad idea 🙂

@hueyp As someone who uses s/conformer quite a bit, I'll caution against specs that transform their data (beyond the conforming that the specs themselves do). Alex Miller and other Cognitect folks also caution against mixing transformation into your specs. The problem is that once you put that in a spec, all client uses of the spec have no choice about the transformation -- they all have to deal with the conformer in the spec.

I’m building a parser and was kind of blown away that with conformer you could totally have it output the AST 🙂

We do it for a very specific use case: where our input is always strings (from an HTTP request) and we want numbers or keywords out of the specs (and they're coded to accept numbers or keywords too, as well as strings).

Yeah... just because you can do something, doesn't mean you should 🙂

exactly why I’m here ! 🙂 thx for feedback~

It's likely to be better for you down the road, to separate the transform to AST from the specs. Otherwise you're complecting validation (specs) with transformation. If you keep them separate, they'll be easier to test and potentially easier to reuse.

Spec is great tho'... we've been using it in production code for quite a while (we have Clojure 1.9.0 Alpha builds in production).

i’m specing a datastructure in clojurescript

and the keys are coming in as strings

I’d like to write the spec with s/keys but that only supports keywords. Am I missing something simple?

I’d rather not coerce the data to use a bunch of keywords cause I have a lot of data

hiya are there any good reference projects or tutorials on how to integrate spec into real world projects

most of the examples i’m digging up explain how it works well but seem “contrived” for lack of a better term

(e.g. modeling decks of cards)

@liamd I suspect most “real world projects” are closed source and can’t easily be discussed...

i mean is spec being used in any popular open source libs?

i guess i’m looking for “best practices”. do i create a new file for my specs, do i do runtime checks with them, etc.

"popular open source libs” are nearly all remaining compatible with earlier Clojure versions...

It’s too early for much in the way of best practices with spec to be codified.

We’re unusual (at World Singles) in being willing to run Alpha versions of Clojure in production.

For libraries that need to support earlier versions of Clojure, specs must be in a separate file so that folks on Clojure 1.9 can require it, but folks on earlier versions can ignore it.

For apps that run on Clojure 1.9, they can have specs inline with functions.

We’ve found the most value so far comes from specifying data not functions. We use spec to validate input parameters for our REST APIs and we’re starting to use it to validate user input in some web apps as well.

So, yes, for us it is runtime checking in production.

But it’s also part of testing — that’s where we instrument code (prior to running our test suite, for example) and some limited automation of generative tests (beware of the increased time such testing takes — consider running it separately from your “unit tests”, so that it can be run “as needed” by developers and as long form testing in CI perhaps).

Does that help @liamd ?

yes absolutely

so what i’m gathering is that standard practices haven’t been established yet necessarily because it’s really still in alpha

i suppose in that case i just have to play around and see what works for me

it seems like there’s lots of space for libraries to be developed on top of spec to enforce certain uses and patterns, like perhaps ring middleware, or test suite integration or cleaner errors from explain

Our experience so far re “cleaner errors” is that requires application domain knowledge, so we’ve created some custom code that maps from explain-data to our application domain, using some heuristics that work for the sorts of spec failures we might reasonably get.

As for the rest of it, yeah, I think it’s just too early for much to have solidified.

that’s actually pretty exciting, i guess i’ll just have to jump in

thanks!

Will you be at Clojure/West later this week?

Nope, I’m in Chicago and don’t have the spare cash. Looking forward to the screen casts that come out of it though.

Is there any way to control the length of keywords generated for the keyword? predicate?