Fork me on GitHub

here is an example: — was doing the first thing and its opaque, tried the second way after reading


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?


thanks! I haven’t used every-kv, but as far as I know using map-of I can’t specify that certain keys are required and others are optional


can that be done with every/every-kv?


You’ll have to use some logical combinations w/ s/and and such, I think


Pretty sure the recommended approach is to conform the keys to keywords. Are you worried about performance?


yeah, worried about performance, a lot of nested maps with strings as keys


perhaps I can replace keys with keywords with specter or something


but yeah, will be converting a couple thousand string keys to keywords, nested to ~20 levels deep, so would like to avoid if possible


No need for specter, I think: Benchmark to see if there’s actually a performance issue. A few thousand keys doesn’t sound like a performance bottleneck.


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).


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


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?