the final idea is to apply authorisation

basically if certain path values of the speced data are “allowed”, the full data could be viewed by a user or not

i’s it more clear now?

could you expand a bit why you think it could be a nightmare?

why would you base something as critical as auth on something as fragile as with-redefs?

sorry i didn’t realise about “These temporary changes will be visible in all threads” 😬 … I was trying for something thread isolated … but with-redefs was my quick first attempt

if you want thread-local rebinding - use binding

though so far the only things I've found with-redef useful for is orthogonal instrumentation of functions (e.g. timing functions) or stubbing in testing

(def ^:dynamic my-fun string?)

(s/def ::simple #'my-fun)

(s/def ::composed (s/keys :req [::simple]))

(s/def ::extra-composed (s/keys :req [::composed]))

(assert (s/valid? ::extra-composed {::composed {::simple "one"}}))

(assert (= (binding [my-fun #{"foo"} ]
             [(s/valid? ::extra-composed {::composed {::simple "other"}})
              (s/valid? ::extra-composed {::composed {::simple "foo"}})])
           [false true]))

(assert (s/valid? ::extra-composed {::composed {::simple "other"}}))

(though since spec I've not really redef'd fns for testing)

example using binding ^^ 🙂

ya - still hard to see how / when you might apply that but at least it's thread-safe now

👍

@U064X3EF3 maybe less nightmare now with binding ?

Less but the idea of changing specs still seems like an idea likely to cause problems later

I'll take into account, thanks both for your help!

If it's a top level spec you can do:

(let [the-spec (if p? ::a ::b)]
  (s/valid? the-spec data))

more than change, the spec should be more specific. so instead of having a predicate string? would be #{"value1" "value2" "value3"}

being these values the returned of a sql execution

I just add the dependency explicitly to the test check namespace

We don't allow test.check as a runtime dependency.

Instead of using the aliased stuff from spec

You can add it as a dev only dependency

Right but then you can't define your generators next to your specs.

Also, you’re depending on it already if you’re actually using any of its functionality

We don't use the functionality in production but want to define the generators next to our specs.

The stuff in spec are merely aliases to the test check definitions

True but it does it lazily -- it only requires test.check if you actually invoke a function in the gen namespace.

I supposed you could use the same strategy

Yes but that begs the question of why it wasn't included to begin with. It may be because it is a macro.

yes, a macro has to run at compile time

so the normal trick that allows you to not have a runtime dependency on test.check doesn't work

So the solution is to copy and paste the let macro elsewhere?

You can do that, you could relax your requirement to not have test.check in prod, you could wrap in a simple proxying macro that expands to an exception throwing generator when tc isn't on the classpath

The problem with including test.check on the cp in prod is certain code paths check input structures via s/valid?. If, by accident, a function is passed in a map of things, it would get generatively checked. That would have a significant impact on performance.

They skip that based on the namespaces being requirable or not?

Not sure what you mean.

If test.check isn't available on the cp and a fn is passed to the s/valid? call, an exception will get thrown.

If it is, no exception is thrown and the performance will slow down silently.

Ah, I see, I didn't notice the "by accident" part In any case, the other two approaches would work though

The latter seems like a good approach. Seems like a worthy addition to the Spec gen namespace as well.

I can see that