On Monday, December 5, 2016 at 11:18:47 AM UTC-6, Tom Locke wrote: > > I'm sure this is a well known issue, but I've not found much written about > it online. > > In the spec guide, we have this example of spec'ing a function > > (s/fdef ranged-rand > :args (s/and (s/cat :start int? :end int?) > #(< (:start %) (:end %))) > ...) > > This form, an s/cat within an s/and, is going to be a standard pattern > whenever you want to express some cross-argument constraint. It will be > common to use keyword references to specs > > (s/fdef f > :args (s/and (s/cat :arg1 ::foo, :arg2 ::baa) > #(... constraint expr ...) > ...) > > The problem is that the constraint expression has to work on conformed > versions of the args, not the simple values passed by the caller, and so is > tightly coupled to the implementation of ::foo and ::baa, and liable to > break when those specs change. >
I'd say that you *are* and *should be* tightly coupled to what ::foo and ::baa are specifying. And you should not "change" them - you should either grow them or create a new name. (See Rich's keynote from the conj.) > There is s/unform, but I've found it to not work in all cases, e.g. > > (->> [1 2 "blah"] > (s/conform (s/coll-of (s/or :i integer? :s string?))) > (s/unform (s/coll-of (s/or :i integer? :s string?)))) > => [[:i 1] [:i 2] [:s "blah"]] > > If I am understanding correctly, I should get the original vector there. > You definitely should. A quick glance indicates that's a bug for coll-of and map-of (and not one I was aware of). Please file a jira. Aside from this problem, it would be a bit cumbersome to have to unform > everything in those preconditions. > There are several kinds of specs that conform to a value other than the original value (not considering nested specs/values) - namely s/or and all of the regex ops. It is possible to undo the conformation with s/conformer (but standard caveats about making choices for consumers of your specs apply). Additionally, there is an undocumented s/nonconforming that will avoid conforming a spec to anything but the original value. Rich is still on the fence about whether this should exist or not so I hesitate to recommend its use (it may be removed in a subsequent alpha) but might be interesting to look at. > Any insight appreciated! > > Tom > -- 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.
