there is a ticket on the way such that (s/def ::foo nil) will be sufficient to remove a spec

@alexmiller thank you!

@ikitommi I just started working with spec-tools but I am finding it a bit hard to write functions dispatching on (s/form spec) as most are wrapped in spec-tools.core/spec. Am I doing something wrong?

@ikitommi ah, I just looked at https://github.com/metosin/spec-tools/blob/master/src/spec_tools/visitor.cljc and it seems you are handling that case by extracting the inner spec

Out of curiosity, what is the consensus regarding issues described here @ikitommi @alexmiller ? https://dev.clojure.org/jira/browse/CLJ-2116. More specifically @alexmiller , you mention > While I think some interesting problems are described in the post, I don’t agree with most of the approaches being taken there. Do you have an alternative approach to suggest? I am a beginner with clojure/clojure.spec but I did find that spec-tools answered some real needs of mine (e.g. strip extra keys when conforming a map)

if you want to transform data, then transform data. why does that need to be in spec?

if the selective conforming only happens at the end, why does it need to be in spec?

the purpose of conforming is not transformation or coercion. it’s to tell you how a value conforms to a spec,

A use case we've found very valuable is using spec for conforming REST API parameters and form parameters -- which all start off as strings but we need numbers or Boolean etc. For those specs, we coerce string input to conformed values. Then we have a single step to s/conform the input map to a validated parameters map.

So at the core, we'll have things like (try (Long/parseLong v) (catch Exception _ ::s/invalid)) as a named spec (predicate).

I would agree with @alexmiller that coercion/transformation beyond that level is probably "doing it wrong".

@seancorfield So you allow clients to send numbers as strings over JSON too?

(and over EDN or Transit too)

We accepted form-encoded POST bodies so it isn't always JSON.

@seancorfield well, a simple case which brought me to try spec-tools was having the ability to strip all keys from a map that were not part of the spec

I assume that, were I to do this myself, I would have to write a function to traverse my spec together with the data and strip keys appropriately?

Why do you need to strip other keys? The only case I can think of is if you send the full hash map to a 3rd party that would object to the extra keys -- and it's safer to explicitly build the map you need at those points.

If your code never uses :x in a map, why do you care that you're passed :x in the first place, is my question.

precisely that; I am transacting the data to Datomic

But you'd be building a namespace-qualified map specific to your schema at that point -- I wouldn't imagine the namespace-qualifier would be the same as your JSON input?

no, but I have a step which namespace-qualifies my JSON input

I think it's a good default to strip extra keys when reading external input. Like rest/http parameters from client

Bit off, but I have a experiment that I use for example /user/%5B%3Auser%2Fuuid%20%23uuid%22123%22%5D (encoded form of /user/[:user/uuid #uuid"123"]) to avoid transformation problems (simple edn/read-string transform types). Not sure if it's a good solution/it's sacale, but it's working well on my tests.