From reddit: > There are a couple areas (spec programmability and some map-related stuff) where we have some work to do.

sounds good, despite doesn't say much about what kind of changes. As there are lot of libraries trying to extend spec for different use-cases, it would be great if the need of the libs could be taken into account. Personally would like to see some public spec walking protocols.

and not based on a parsing spec forms, that we can do outside, more like CLJ-2251.

a library developer feature poll/discussion?

@richiardiandrea you can create ns and give it an alias, it will not be tied to an actual file, but you will be able to use that alias to shorten keywords. it is not pretty though. clojure.core/create-ns, clojure.core/alias. I found, that having shorter spec names is less tedious and more readable (possible in app layer, where your system is pretty much the only system which sees them). In libraries you probably would want to use longer "truly" global long keywords for under the hood things.

Hi, I am using spec for the first time. And it takes too long to generate my specs using (test.check/generate (spec/gen ,,, )). I had previously used test.check for similar data generation and did not had the problem. The spec if the configuration map having many nested spec/keys and spec/every. Limitin spec/every with :gen-max did not help. What am I doing wrong ?

Heres part of the spec ... the final configuration contains a numbeer of :ecosystem/service-instances

If you have a lot of s/every, they will gen up to 20 elements. Setting :gen-max in those to something like 3 would probably help

What’s the preferred way of specing a spec? I have an internal lib function that takes a spec and I want the s/fdef to check that the arg is a spec. So far I have qualified-keyword? But that’s a bit of a shallow spec? Tried spec? But it was returning false on s/def’d qualified keys.

That spec arg is later used in internal machinery to validate some request routing

@dadair Remember that a predicate function could also be (treated as) a spec...

Yeah, at this point I force using a “defined” spec

Maybe call s/form on it and succeed if you get truthy?

Maybe expect users to wrap in (s/spec ..) prior to passing argument, then internally spec against s/spec??

that would also get around the limitation of removing the ability to use a raw predicate

Are there any downsides to that approach? I’m not super familiar with the effects of (s/spec ..)

There's a get-spec function you can use with the qualified keyword (rather than s/form). You can wrap anything in s/spec: (s/spec 42)

So (s/spec? (s/spec 42)) is truthy -- so it won't tell you it's really a spec that is wrapped.

Yeah maybe I need to do some code-based validation rather than relying on the fdef here

It’s not a critical check, I’m just trying to add some guardrails for the other devs that aren’t super familiar with this part of the system

I guess I'd take a step back and ask: Am I over-constraining this function?

Can it accept a predicate and use it like a spec, for example?

Yeah, that’s what I’m thinking too.

specs can be qualified-keyword?, set?, ifn?, or spec instances (there’s a s/spec? for those)

Should I be using (spec/fdef ...) for multimethods (does not seem to work)? Guess I can just wrap the defmulti invocation in a function and test that...

Erroneously thought that multi-spec was for multimethods, but it actually appears to be for dispatching data based on "kinds".

nm, silly ns error. spec/fdef does appear to work with defmulti