If you name (register) your (sub)specs with s/def and you can reuse them as
much as you like.
(s/def ::argi (s/cat :i integer?))
(s/def ::fnii (s/fspec :args ::argi :ret integer?))
(s/conform ::fnii +)
(s/valid? ::argi '(42))
However you are talking about calling ‘instrument’ so I don’t think you are in
the HOF case. So you shouldn’t be using fspec but fdef:
(s/fdef fooi :args (s/cat :i integer?) :ret integer?)
(defn fooi [i]
(let [spec (-> `fooi s/fn-specs :args)]
(assert (s/valid? spec (list i)) (s/explain-str spec (list i))))
42)
(fooi "42")
user=> AssertionError Assert failed: In: [0] val: "42" fails at: [:i]
predicate: integer?
Obviously some macrology could make this more succinct, as is being discussed
elsewhere.
> On May 26, 2016, at 9:17 AM, Wesley Hall <wesley.h...@gmail.com> wrote:
>
> spec is not a contract system.
>
> Forgive me for I am about to sin :).
>
> I have a little RPC framework that I use to do simple remoting between
> clojurescript in the browser and ring based web services. I'm currently using
> schema to validate arguments received from clients and return appropriate
> exceptions upon non-conforming invocations.
>
> The idea of being able to perform generative testing against a specification
> for these functions is really appealing but if I am using generative testing
> to verify that my functions behave properly if invoked as intended it does
> feel like there would be some benefit to ensuring that the conditions under
> which the function has been tested are enforced at runtime for those
> functions on the edges of my API.
>
> I'd definitely prefer a manual conformity check over instrumentation in these
> cases, but it seems like an fspec cannot be used for this purpose (from
> within the function itself). I'd rather not define my specs twice.
>
> Seems like I might be destined to make cheeky instrument calls after each of
> these edge functions, in the same was the always-validate metadata is used in
> schema.
>
> Do I have a desperate need to be convinced otherwise? :)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
