You just need to come up with qualified names for them:
user=> (require '[clojure.spec :as s])
nil
user=> (s/def :base/attack (s/and integer? pos? #(<= % 1000)))
:base/attack
user=> (s/def :base/bonus (s/keys :req-un [:bonus/category]))
:base/bonus
user=> (s/valid? :base/event {:attack 100 :bonus {:category {:heavy 100}}})
true
Not sure about channels.
On Friday, May 27, 2016 at 12:36:56 AM UTC-7, Pedro Pereira Santos 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 <javascript:>>
> 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 clo...@googlegroups.com
>> <javascript:>
>> 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 <javascript:>
>> 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 <javascript:>.
>> 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.
