implications for test.check?

[Stuart Halloway]

Gary points out that "clojure.spec seems to make the test.check API more important and harder to change". [1]

test.check is now more important, for certain.  But I hope we make *everything* harder to change.  In the rationale for spec, Rich says, "Programmers suffer greatly when they redefine things while keeping the names the same."  In Clojure, we have some of the tools we need to do better, starting with good namespaces.  So instead of changing test.check (or anything else), let's aim for compatible additive enhancements.  There is no shortage of namespaces.

I am happy to review any work done enhancing test.check, and I would love for Gary (or anyone) to review and improve the gross thing [3] I did to flow explain-data through quick-check.

Stu

1. https://twitter.com/gfredericks_/status/734876301958512644

2. http://clojure.org/about/spec#_enable_and_start_a_dialog_about_semantic_change_and_compatibility

3. https://github.com/clojure/clojure/blob/master/src/clj/clojure/spec/test.clj#L20-32

[gfredericks]

Thanks Stu.

I will look deeper into how test.check and clojure.spec are tied together and how that might relate to changes I was considering, and will probably start a separate thread on those topics.

I wouldn't want to add to this thread without also quoting a tweet, so I will point out Nicola's reply, asking "isn't that what version numbers are for? I certainly don't want to require `test.check.next` or `test.check2`". [1]

I had similar thoughts myself when I first read this post, and have been trying to piece together what it looks like in practice for a library to use new namespaces to avoid breaking changes. My initial thought was that you would at least want to minimize how often you reboot a namespace, but I couldn't come up with a solid justification for that beyond a vague distaste for a project with the code spread out over nine variants of the same namespace. But in any case I assume the "compatibility checking" rich mentions is a strategy for making safe changes to APIs without having to reboot the namespace. I would be interested to hear more thoughts about this.

Gary

1. https://twitter.com/Bronsa_/status/735026844379062277