During development, does it makes sense to use fdef and instrument for all my functions or sprinkle my functions with assert and old enable assertions during development? Perhaps a combination of the two?

I guess the benefit of fdef is that it can be in a separate namespace; is that recommended?

It seems like that would defeat some of the namespace'd keyword designs of spec though.

@alexmiller hi! We found strange flawing bug for clojure.spec lib in multithreaded environment. We use latest clojure.spec versions ("0.2.176" "0.2.44") for request validation. Every http request we translate to clojure map, then we call (s/valid? spec input-request-map) for input validation. We have 300 000 sample requests (saved in edn file) for testing (constant requests). If we use one thread on JMeter to send request then we always have result true for (s/valid? spec input-request-map) for every 300 000 constant requests. if we use 2 threads or more on JMeter to send requests then sometimes we have false result. If we save false map to a file and then try to validate it (s/valid? spec input-request-map) then we see that it is always true. If we validate twice in multithreaded env (or (s/valid? spec input-request-map) (s/valid? spec input-request-map) ) then it works (but logs tell us that one of s-exps inside or sometimes false). All map is standard clojure maps (immutable). The code (or (s/valid? spec input-request-map) (s/valid? spec input-request-map) ) works for us as workaround but we can't watch on it without crying. It's Clojure, but we met undefined behaviour like in mutable world.

Any advice?

@djtango If you are using Leiningen, the command lein deps :tree can be useful. With tools.deps there is clj -Stree. Maybe you were already aware of those and looking for something more, though.

So, I added (clojure.spec.test.alpha/instrument) to the bottom of my core.cljs file, however I have a namespace alpha which defines a symbol (def global (beta/example ...)). The problem being that core depends on alpha which uses beta/example prior to it being instrumented. Do I have to add the instrument to every namespace to avoid this?

How do I spec and instrument functions that will be used during initialization?

How would you spec standards based things. Country codes for example: https://en.wikipedia.org/wiki/ISO_3166-1_numeric

This is where I am so far. (s/def :iso/country-code (s/and s/string? #(= 3 (count %))))

@jaihindh.reddy in these kinds of cases I enumerate all the possibilities in a set and use that set in the spec.

@taylor ISO charges money for downloads of data. But it is freely available on their website. Scraping that would be awkward to say the least.

e.g. (s/and string? countries/all-country-codes) where all-country-codes is a set.

in your example all the ISO codes are on the Wiki page

I generate from https://github.com/lukes/ISO-3166-Countries-with-Regional-Codes

…which also makes it somewhat maintainable in the longer term.

are you concerned with keeping the list fresh as time passes?

Ideally I would love to do something like (into #{} (slurp url-for-all-country-codes))

yeah, that's a separate problem from clojure.spec

Country codes should be relatively stable. Dont mind manually updating it

Well, manually is fine, but I would plan on doing it every once in a while. The list of countries is actually surprisingly unstable.

Can I spec protocols and multimethods?

See https://dev.clojure.org/jira/browse/CLJ-2109

I think you're OK with multimethods tho' (I saw a CLJS ticket that indicated s/instrument was fixed to work with multimethods, so I assume it works in CLJ too).

On that note, when should I use one or the other?

Currently I think protocols should be the default, and multimethod if you think you need the arbitrary dispatch.

@jaihindh.reddy I think this is still a good set of guidelines https://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/