You can’t give the same qualified spec name two meanings, that’s a main point
of spec. However, your actual use case you use unqualified :attack in two
different contexts. - just don’t map them to the same spec. Note that ::kw is
just a shorthand in the examples for fully-qualified keys, they need not be in
the same ns.
e.g. register specs under
:my.simple/attack
:my.complex/attack
and then in one context use (keys :req-un [:my.simple/attack …]) and in the
other (keys :req-un [:my.complex/attack …])
> On May 27, 2016, at 3:36 AM, Pedro Santos <donbonifa...@gmail.com> wrote:
>
> Hello,
>
> How can I differentiate between the same keyword, but with difference
> semantics? Example:
>
> {:attack 100
> :bonus {:attack {:category {:heavy 100}}}}
>
> I have:
> (s/def ::attack (s/and pos? #(<= 1 1000))
> (s/def ::bonus (s/keys :req-un [::attack ; <---
>
> Is there a way to do this?
>
> --
>
> Another question: is there a way to spec a fn that handles channels?
> Something like:
>
> (s/fdef some-fn
> :args (s/cat :ch (s/chan ::unq/model))
> :ret (s/chan :unq/model))
>
> --
>
> And yet another: I have a game project with some test.check scenarios. The
> test run takes 8s without instrumenting and 22s with instrumentation, and
> this makes me think on starting to split tests in test suites. Is there
> something to handle this in clojure.test?
>
> Thanks!
>
>
> On Thu, May 26, 2016 at 7:00 PM Beau Fabry <imf...@gmail.com> wrote:
> 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.
>
> --
> 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.
