Fork me on GitHub
#clojure-spec
<
2020-01-06
>
borkdude15:01:35

I'm in the process of writing a version of spec(1) that can be used with babashka. For now it's an interpreted lib:

$ export BABASHKA_CLASSPATH="$(clojure -Sdeps '{:deps {spartan.spec {:git/url "" :sha "104129aae9eab6dd4622937d0f46abeed9c9c537"}}}' -Spath)"
$ bb -e "(require '[spartan.spec :as s]) (s/explain (s/cat :i int? :j string?) [\"foo\" 1])"
"foo" - failed: int? in: [0] at: [:i]
I'm unsure what parts I could be adding to babashka as a built-in. Are there any assurances what parts of the API will be unchanged, and what the future namespace of spec will be ?

holyjak06:01:27

Why not spec 2? Though not finished, I guess it bears completion (just the last 10% that use 90% of the time :rolling_on_the_floor_laughing:)...

borkdude15:01:56

If I have some more assurances, I could adopt parts of this lib as built-ins which would make it much faster.

alexmiller15:01:47

I can assure you that the future namespace will be different :) The current spec 2 is clojure.alpha.spec, clojure.alpha.spec.gen, etc. We're expecting this to eventually be clojure.spec, clojure.spec.gen

alexmiller15:01:55

most of the existing spec forms will probably be the same, with some additions and some fine details changing around a few things (and deprecation/removal of s/keys)

alexmiller15:01:51

most of the spec operations will be the same although we have added arities in all of the conforming ops (valid?, conform, explain, etc) to support spec checking modes

seancorfield17:01:50

@alexmiller Any sense yet of whether there will a migration path/tooling at launch of clojure.spec?

alexmiller17:01:08

as long as there are no follow-up questions, yes :)

lgessler23:01:19

hi, I want to use s/fdef with protocol functions. In one namespace, I'm calling fdef and defining and implementing a protocol, but the protocol's methods appear to be unaffected by fdef. If I understand [this issue](https://clojure.atlassian.net/browse/CLJ-2109) right, this is expected behavior. Is that all right, and if so, is there a recommended workaround for speccing protocol functions?

alexmiller23:01:46

That’s correct - fn specs don’t work with protocol methods. Only workaround I’d suggest is wrapping the call to the protocol function in a method (which I often do as a matter of practice anyways)