Fork me on GitHub
#clojure-spec
<
2018-10-27
>
misha01:10:06

@ariel.silverman what does "exclusively" mean here exactly? only those keys, and no others? are those qualified keys? do you have value specs too, or is it just keys?

đź‘Ť 4
asilverman16:10:03

Thank you misha for the very thorough explanation. The code snipped was extremely helpful, as @seancorfield mentioned, I also asked this question in the #beginners forum. The idea was to limit an API endpoint query parameters to a known set and error out when anything but a valid sub-set of them is passed down. Thank you again!

misha01:10:33

and a due disclaimer "clojure.spec is explicitly designed to discourage closed maps ("no keys except these")"

seancorfield01:10:32

(it was answered in #beginners )

souenzzo13:10:03

#datomic query returns a java.util.HashSet, that prints like a set but it's not a coll?. So I cant use s/coll-of on it. I changed my spec from (s/coll-of ::stuff) to seqable? Should spec have a s/seq-of that use seqable? or somethink like that?

dangercoder16:10:41

Is running (spec/explain ::foo data-structure) in the beginning of a function bad practise?

dangercoder16:10:11

I'm using spec/fdef right now and turning on instrument in dev-environment.

borkdude16:10:40

Nothing’s bad, just depends what you want

dangercoder16:10:13

True, I was thinking if there can be some kind of noticeable performance loss if having instrument on in production, but i'll have to measure and see later on.

borkdude17:10:08

yes, this definitely affects performance

andy.fingerhut17:10:14

I don't have any measurements of a real application with instrument on vs. off, but I do have measurements for clojure.set functions with instrumentation on vs. off, for a simple spec that just checks whether the args satisfy set? or not. It is partway down the README on this page: https://github.com/jafingerhut/funjible#wait-isnt-this-what-clojurespec-is-for

borkdude17:10:12

I had enabled speculative that has some amount of core specs. My backend + frontend became significantly slower.

andy.fingerhut17:10:17

instrument in that case is significantly slower than the original functions when their run time is short. The percentage overhead obviously gets smaller as the run time of the instrumented function increases.

borkdude17:10:05

I think how may want to use “instrument all” is when I have some weird bug whose stack trace I find uninformative. Then instrument all, run again, find the problem, turn it off.

dangercoder17:10:55

@borkdude sounds like a solid approach

borkdude17:10:40

some specs I do want on all the time in dev, especially at boundaries like DB insert queries

borkdude17:10:02

it’s a tweaking process I think

seancorfield18:10:43

As another data point for the overhead of instrument: clojure.java.jdbc has its specs in a separate namespace and the time difference between running the tests with and without instrumentation -- just on the public API functions -- is huge. I would be extremely careful about turning on instrumentation in production.

đź‘Ť 4
seancorfield19:10:35

Another thing to watch for: if you have a higher-order function instrumented, you'll invoke generative testing on the (function) argument being passed in -- which you almost certainly don't want in production (you probably wouldn't even want org.clojure/test.check included as a dependency in production?).

dominicm19:10:10

We've been using s/assert to have dev and production operate differently.

asilverman16:10:03

Thank you misha for the very thorough explanation. The code snipped was extremely helpful, as @seancorfield mentioned, I also asked this question in the #beginners forum. The idea was to limit an API endpoint query parameters to a known set and error out when anything but a valid sub-set of them is passed down. Thank you again!