Fork me on GitHub
#clojure-spec
<
2016-06-28
>
Oliver George03:06:53

New favourite spec trick. Wrap your spec to generate warnings instead of erroring out.

(defn warn
  "Throw warning if spec is invalid but always pass."
  [spec]
  (fn [x] (when-not (s/valid? spec x)
            (js/console.warn (s/explain-str spec x) x))
    x))

Oliver George06:06:23

And now not. Turns out the stack trace from normal errors is more informative (cljs).

rauh08:06:35

I have within one ns two different specs for :db/id (one for data coming from datascript and one for datomic ids). How can I specify this in spec?

puzzler10:06:15

How would you specify a "vector of anything"?

puzzler10:06:57

(coll-of ??? [])

puzzler10:06:03

What goes in the ??? position?

puzzler10:06:16

Is there some sort of top-level type in spec?

puzzler10:06:25

I guess I could just use vector?, but I'd like it ideally to generate lots of random Clojure things to go in the vector.

puzzler10:06:41

Similarly, what about a map where the keys can be anything but the vals are more restricted?

puzzler10:06:27

(map-of ??? integer?)

rauh10:06:37

@puzzler: (spec/coll-of ::spec/any [])

puzzler10:06:34

Hmmm, looks like that conforms non-vectors too.

puzzler10:06:37

Where is ::spec/any documented?

jannis12:06:39

@puzzler: (s/spec vector?)?

Alex Miller (Clojure team)12:06:28

There is new support for this in next alpha

jannis12:06:05

I have a lot of vector?-based specs that currently all require custom generators.

Alex Miller (Clojure team)12:06:51

coll-of has many new options

Alex Miller (Clojure team)12:06:47

Can now indicate the expected incoming type separately from the conformed and generated type

Alex Miller (Clojure team)12:06:22

Also, Rich added s/merge yesterday to create spec that merges multiple map-validating specs and will gen as you expect (union of keys)

Alex Miller (Clojure team)12:06:20

@jannis in next alpha you will be able to do (s/coll-of int? :kind []) to indicate a vector of ints

puzzler12:06:15

When a spec is complicated and composed of many component specs, I'm having trouble figuring out, stylistically, which of those component specs to register to namespaced keys, versus just def'ing them to regular vars. Any tips on this?

puzzler12:06:33

It seems to me that when spec'ing a bunch of optional keywords for a function, to get good error messages I really want to be able to say "These are the only keys allowed in this map of optional keywords and values". Is there any way to do that?

Alex Miller (Clojure team)13:06:00

generally, I think you should not def anything to a regular var

Alex Miller (Clojure team)13:06:36

and you should register specs for all map attributes and for any major “types"

Alex Miller (Clojure team)13:06:58

anything recursive will require registration at the recursion points

Alex Miller (Clojure team)13:06:33

and you might want to register things at a finer granularity if you find it gives you more meaningful explain errors

Alex Miller (Clojure team)13:06:39

re restricted key sets - no, this is intentionally not provided, but you can s/and a constraint like #(every? #{:allowed :keys :in :map} (keys %))

puzzler13:06:33

Thanks. Early on, I predicted that a lot of people would re-invent slightly different definitions of validating or conforming combined with assertions in the event of a failure, and I've been seeing that happen. Is something along the lines of assert-conform and assert-valid? likely to make it into a future alpha?

Alex Miller (Clojure team)14:06:13

yes, there are likely to be a conform-ex and some kind of assert, but I don’t think those will be in next alpha

bhauman15:06:58

I've been wanting to add an extended :reason to certain specs, especially if they have strange interdependencies

bhauman16:06:31

If you look sideways at this you could see the possibility of specs with composable prose explanations

kendall.buchanan20:06:47

Super quick question: If I’m referencing a spec in another namespace, do I need to :require that namespace too?

kendall.buchanan20:06:10

I’m finding the app runs fine in the REPL, but at compilation, it can’t resolve the specs.

bhauman20:06:30

If I'm understanding you correctly, all specs need to be required before use

bhauman20:06:40

in order for the registry to populate

kendall.buchanan20:06:05

Okay, I was afraid of that 😉

martinklepsch20:06:36

So, form-validation & clojure.spec, I assume people have tried it already, are there any writeups/snippets?

martinklepsch20:06:19

@bhauman: @kendall.buchanan I find it interesting that this can create an implicit dependency between namespaces that is not declared via the ns form, maybe for "good style" you should require the ns containing the spec even if you don't need to (technically)?

kendall.buchanan20:06:00

I’ll admit – I still find the coupling between specs and namespaces odd. Namespaced keywords seem to make sense when you’re trying to define a domain path, but sometimes those domain paths don’t match your namespace hierarchy. But Clojure basically says it has to.

kendall.buchanan20:06:12

Still struggling to understand it. But, seems fine.

bhauman20:06:54

@kendall.buchanan: you are aware that you don't have to use an existing namespace correct?

bhauman20:06:04

just a namespaced keyword

kendall.buchanan20:06:31

Yeah, totally, but I guess I’m struggling to see the established path forward.

martinklepsch20:06:33

> but sometimes those domain paths don’t match your namespace hierarchy

martinklepsch20:06:35

👍 (same struggle here)

bhauman20:06:11

In terms of dependency management, I think if people look at the way they did plumatic/schema or any add hoc type validation.

bhauman20:06:24

it's like any dependency

angusiguess20:06:29

We've started defining a lot of our specs in a separate heirarchy. It's a bit early to tell how well that works but thus far it's been pretty useful in terms of reducing circular dependency issues, making specs equally usable in tests and code, etc.

kendall.buchanan20:06:30

@bhauman, would you recommend (or consider as a viable path) to always use domain-based keywords school/:type and eschewing ::type (contained in my.app.model.school? Just ditching the latter pattern?

angusiguess20:06:06

So that's one possibility, is to use ::type but to place those definitions in a namespace that is a little descriptive of the domain model.

bhauman20:06:29

I wouldn't be the one to ask, but I would say no

bhauman20:06:48

A possiblity: As long as your keys are distinct, you can keep it all in one file.

kendall.buchanan20:06:53

@angusiguess: Kind of like app.spec.school/type? That’s more or less what I’ve done for objects that cut across many domains.

angusiguess20:06:14

@kendall.buchanan: That's precisely what I do, including a namespace for more generic types.

angusiguess20:06:30

Like

app.spec/uuid-str
or similar.

kendall.buchanan20:06:47

Yeah, exactly what we’ve started doing.

angusiguess20:06:22

Then if we have aggregates that our functions take we'll define them in the function's namespace.

kendall.buchanan20:06:27

And I think it works well. I guess I like the ::thing syntax, for brevity, and realize it ties things up into the namespace. I guess we’re learning as we’re going, though.

kendall.buchanan21:06:37

(By the way, I have no proposed alternative, so not complaining. Just been a source of friction for me.)

angusiguess21:06:49

Defining everything in-line bit us pretty quick.

kendall.buchanan21:06:28

Right, @angusiguess… which, I have to say, clojure.spec is what it claims: built for composability. I’ve been a heavy Schema user, and have to say, I’m getting more reuse out of spec by far.

Alex Miller (Clojure team)22:06:13

Clojure 1.9.0-alpha8 is now out with lots and lots of spec updates https://groups.google.com/d/msg/clojure/vF3RuDWuX8I/pvn4IUuUAwAJ

richhickey22:06:53

Lots of new spec stuff in alpha 8 - conforming coll support, plus count/kind control, instrument can generate stubs, gen/spec overrides in instrument/test, merge keys specs

Tim23:06:39

wow sounds good