Sorry if this is coming through a second time, I'm not having much luck with google groups.
> OTOH, you may encounter user- or externally-supplied data at runtime and want to use the facilities of spec to validate/process it. Then you can use valid? or conform *explicitly* to do so. Expanding on the use case of user-supplied data, would it be possible for predicates to have additional information in some way for this purpose? Sometimes you only have the information you need to validate data, at runtime. For example user registration requires a check that the email isn't already registered. So to check it, you would need to provide a reference to the current database. Under the current api, I would need to make that db reference part of my data, or provide it through dynamic vars. Neither of these are ideal, as my database isn't part of the user-supplied data, and dynamic vars remove code locality. I think that, where possible, it's always best to pass all the arguments that a function needs. Will the spec api open up for this in the future? Or is this not a scenario that spec will ever support? On Wednesday, 25 May 2016 13:30:03 UTC+1, Rich Hickey wrote: > > > Would you ever expect to use fdef/instrument active in production for > validation > > No, definitely not. It’s that kind of runtime checking (and expense) that > gives some dynamic lang checking systems a bad rep. > > The philosophy is - generative testing has made sure your function > complies with the specs. So, testing the :ret and :fn properties over and > over is redundant and serves no point. > > OTOH, you may encounter user- or externally-supplied data at runtime and > want to use the facilities of spec to validate/process it. Then you can use > valid? or conform *explicitly* to do so. > > The intent is that running with wrappers (instrumentation) should be done > only during testing. > > > On May 24, 2016, at 7:43 PM, Elliot <ell...@deck36.net> wrote: > > > > Super super excited for this feature, thanks so much for creating this. > > > > In the runtime-validation case, the guide mentions: > > > > 1. Calling `valid?` in a precondition > > 2. Calling `conform` in the fn implementation > > > > However neither of these appear to use the `fdef`/`instrument` combo, > which seems the closest to "type annotating" the function. Would you ever > expect to use fdef/instrument active in production for validation, or is > that a misunderstanding of its use? > > > > Thanks! > > > > - E > > > > > > On Tuesday, May 24, 2016 at 11:12:59 AM UTC-7, scott stackelhouse wrote: > > I restructured my data to make this section an optional sub-map, which I > think is actually better anyway. > > > > On Tuesday, May 24, 2016 at 11:08:27 AM UTC-7, scott stackelhouse wrote: > > Ok. > > > > Thanks all who have worked on this, btw. It is incredibly timely for me > and is already great help for a work project. > > > > --Scott > > > > On Tuesday, May 24, 2016 at 10:57:26 AM UTC-7, Rich Hickey wrote: > > ‘and' and ‘or’ are not currently supported in :opt > > > > > > > On May 24, 2016, at 1:45 PM, scott stackelhouse < > scott.sta...@gmail.com> wrote: > > > > > > I'm having a problem writing a spec for a map with some required > keywords and some optional keywords. The caveat here is that the optional > keywords are all or none... that is they are optional but if one is present > they must all be present. > > > > > > What I tried to write was: > > > > > > (s/keys :req [::a ::b ::c] :opt [(and ::d ::e ::f)]) > > > > > > and that fails an assertion. It appears that the logicals (and, or) > are not allowed in the optional section? > > > > > > Am I thinking about this in the wrong way? > > > > > > --Scott > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- 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.
