I recall reading advising caution on using conform awhile back. Is this still the case?

are you sure it wasn’t caution on using conformer?

i can’t be sure

what’s the downside in any case?

for conformer, if that’s what it is

conformer enables your specs to do a little bit of data coercion

sometimes that’s useful to make a spec work, but it’s usually better to do that work in a function rather than a spec

ie just translate the data and spec the data that exists before and/or after that translation

that’s my best attempt as a short explanation, but others here can probably elaborate

okay cool, so there’s no problem with conform then in both the latest cljs and clojure right?

yeah, definitely not - conform is a non-trivial part of the utility of spec 😉

perfect, gonna save me a non-trivial amount of time writing destructuring branches on my multispecs 😉

Paraphrasing Alex: if your spec also coerces data, bear in mind that this coercion will apply to all clients of that spec.

At World Singles, we have a lot of specs that coerce string data to typed data. We’re OK with that 🙂

Specifically, we have specs for our API calls that accepts strings as input and the result of conforming them is domain model values (so string -> long in some cases and string -> keyword in others).

We generally write the specs for the domain model values first, and then write the API specs in terms of those (so an API spec is (s/and string? (s/conformer some-coercion) ::domain/spec-name) and we have a generator that fmaps the reverse coercion over the ::domain/spec-name (either str or name usually).

We have some shorthand coercion specs tho’ (e.g., ->long which does (try (Long/parseLong s) (catch Exception _ ::s/invalid))).

aha

i guess it’s extremely helpful when dealing with 3rd party APIs

i think what seancofield is saying, and by extension alex, is that conformer couples some interpretation of the data to the specification - however somebody else may want a different interpretation. so if you choose to use conformer, you prevent yourself and others from being able to apply a different interpretation

is this the reason to use caution and not that it’s in alpha?

if you don’t expect to ever need another interpretation, then go right ahead, but just know you’re making that trade off

for conformer specifically, yes

perfect thanks

seancorfield: the other option would be to not use conformer and then to do a secondary pass where you apply coercions, right?

i’ve been hacking on this thing: https://github.com/brandonbloom/ambiparse and i made a decision up front to include semantic rules as a primary feature - it’s basically the same idea as conformers

but parsing is different than validation - in parsing, you’re pretty certain to have a lot of “trivia” like whitespace etc that you want to discard

@bbloom My objection to that is that you end up doing the work twice: once to determine whether a value is valid and then again to actually convert it — since you always want to convert it if it is valid.

I mean, you could use a regex I suppose to say “It’s valid if it’s just digits and not longer than N” but that’s not the same as actually parsing a string to get a number — you’ll either allow too many digits or not enough.

And if you decide to use a regex, now you have two problems 🙂

sure, the guidance is essentially “consider if you might want to NOT convert it in the future” - and if the answer is “nah, i’ll never need not do that” then go right ahead

there’s sorta a 3rd approach

which is what instaparse does: allow you to specify rewrite rules independently

And it’s easy to write a non-coercing version of these specs: you just call str or name on the conformed result 🙂 (s/and ::api-spec/spec-name (s/conformer str)) 🙂

so like you’d have a map of specs to post-conformers

the amazement of discovering exercise is like using the repl for the first time

is there a way to pprint the output though?

you can just call clojure.pprint/pprint

or you can use something like https://github.com/greglook/whidbey

https://clojure.github.io/clojure/clojure.pprint-api.html#clojure.pprint/pp

yeah i think it’s fine, it’s just pulling out the common namespace part of the keywords but I guess this is normal behavior for pprint

like [#:firstpart {:next “blah"}] for things that are :firstpart/next

@naomarik yes that's new syntax for namespaced keys in maps (namespaced maps?), I think it has been added in the first 1.9-alphas. They will all print that way

ah ok the bot is not on 1.9 yet

(get #:test{:foo 1 :bar 2} :test/foo)
1

ahh okay

Do specs belong with my application code or should I put them in their own namespace? Also, should I assert within application code or use the :pre and :post keywords to check my function i/o?

i asked the same question about where to put specs - it seems like both options occasionally make sense

it seems like if you have a single-namespace that wants to export some specs, go right ahead and put them inline

if you have a bunch of namespaces collaborating around some common stuff, maybe put the specs in their own namespace

start single-file and go multi-file if you need to

the only decision you really need to make up front is what namespace you want them to land in in terms of usage externally

there’s also a risk of a circular dependency between the spec namespace and the other namespaces

@kyle_schmidt As for assert / :pre / :post — “it depends”.

I would normally turn on instrumentation as part of my tests, and have certain tests that run check on key functions (ones that can be generatively tested). I generally do not have assert in any production code and only very rarely have :pre or :post.

Thank you for the replies. And just to make sure, is clojure.spec a replacement for clojure.test? Or would I still want to write both?

In my experience in practice you wind up writing both.

spec is definitely not a replacement for test

you use your specs from tests

at least that’s one use of spec

oh interesting. so use specs to aid tests

Ah, I interpreted that question as being whether clojure.test.check replaces clojure.test.

@kyle_schmidt: there’s a bunch of spec videos by stu halloway on youtube that are a good intro of actually doing some testing w/ spec

cool thanks I’ll check them out!

Is there a way to spec out a function as part of a collection, such as a map? For example, if I define a spec like:

(s/def ::callback (s/fspec :args (s/cat :x number?) :ret number?))

(s/def ::foo (s/keys :req-un [::callback]))

I think in practice, I would typically just spec out the function I was using as the callback itself, and spec the key as just fn?. It seems simpler, but I wasn't sure if I was thinking about this correctly

@lambdahands I get true for that valid? call

yeah, I would expect that to work

Hmm. I am using clojure-future-spec – let me try with the latest alpha as well.

(also ifn? is usually better than fn?)

Ah, thanks for the tip @alexmiller!

@naomarik you can also turn off namespace map syntax for maps if you want (set! *print-namespace-maps* false)

it will default to false in Clojure but true in the repl

Checked out that spec again, and it does work as you said. Strange, I must have been doing something wrong earlier as I was getting an unexpected result.