Fork me on GitHub

is it possible to run count of (s/def #{"a" "b" "c"}) ?


is that s/def missing a name?


e.g. (s/def ::foo #{1 2 3})


anyway if your spec is a literal set, you could do

(s/def ::foo #{1 2 3})
(s/form ::foo)
=> #{1 3 2}


or you could define the set separately, and reference it from the s/def and wherever you need to count it


how can I find out how many elements there?


Is there a way to abstract over whether a key in a map is namespaced or not? In a certain context, as long as the value conforms, I want to accept both with the same spec.

Alex Miller (Clojure team)02:12:29

If you’re using s/keys, the :req-un and :opt-un will do that


Can I spec record methods just like any ordinary function?


The guide does not really go into details on records, except that one can spec their fields/attributes:

Alex Miller (Clojure team)17:12:18

records don’t really have methods

Alex Miller (Clojure team)17:12:33

they implement interfaces/protocols which define methods

Alex Miller (Clojure team)17:12:47

currently, you can’t spec protocols or interface methods

Alex Miller (Clojure team)17:12:27

and because of the calling implementation it’s not possible to instrument them (and probably not something we’re ever going to really do because of that)

Alex Miller (Clojure team)17:12:52

but I wouldn’t completely rule it out


@alexmiller So I can spec neither the protocol for all its implementations, nor every record implementation individually?


But I could place the implementation in a function, which I could spec, and then from the record implementation just call that function? I.e. insert one step of indirection?

Alex Miller (Clojure team)17:12:41

yes, but I wouldn’t do that just to be able to spec it


Well, right now my implementations look like (s/assert ...args...) (s/assert ...body...), which is hardly better...

Alex Miller (Clojure team)17:12:06

this is a case where the impl of protocols (designed to tap into the highly optimized java/jvm calling semantics) is at odds with the dynamic indirection possible in Clojure via vars

Alex Miller (Clojure team)17:12:04

I guess maybe there’s some possible future where newer Java capabilities like method handles could be used to implement this kind of thing

Alex Miller (Clojure team)17:12:48

retaining most of the speed but also giving you the dev time instrumentation


So what do you do when during development you want to ensure that the maps returned from a method implementation of the record conform to a spec? And that all callers call it properly? Insert (s/assert arg-spec arg) (s/assert ...body...), like I did?


I don't really care if the call slows down by an order of magnitude, if it helps me in debugging where that borked data came from.


Or do you just split up the code in such small pieces that the method implementation in the record does not really do any significant work anymore, so you have enough functions that you can properly instrument?

Alex Miller (Clojure team)17:12:08

I don’t think there is one canonical answer to that question, it depends on the code

Alex Miller (Clojure team)17:12:03

splitting up code into smaller pieces is usually a good idea though


Thanks, I'll start with that then, maybe it already alleviates the problem.


Is there any work yet on determining whether a spec is a subset or a superset of another? I think Rich has hinted at this a lot.


is anyone using (s/cat ...) to spec strings? I realize I could just delegate to a traditional string regex with (re-matches ...), but then I give up on high-fidelity explain results no?