I'm in a similar position to you Wesley, I'm all for generative testing, but sometimes I prefer not to spec out the full depth of the tree (ie some input leaves with s/Any) and just turn on validation in staging and see what happens. The cpu-time wasted there doesn't matter much to me. Looking forward to seeing where things end up. Spec certainly seems really well thought through.
Aside: Great work on the docs Alex. Much much more comprehensive and readable than is usually available for an alpha feature in *any* language. On Thursday, May 26, 2016 at 6:57:24 AM UTC-7, Wesley Hall wrote: > > Thanks Rich, for this and your work in general. After 15 years of working > with Java, it has been a real joy to find clojure (let's face it, that pun > alone is pure gold!). > > I might try my hand at the macrology you describe as an exercise... > everybody stand well back.... > > On Thursday, 26 May 2016 14:43:04 UTC+1, Rich Hickey wrote: >> >> 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 <wesle...@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 clo...@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+u...@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+u...@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.
