> 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.
With regards to this use-case, I was wondering if there were any plans for
spec to allow for additional information to be passed to the predicates in
some way?
A practical example for my question is user registration, I need to check
that the new user's email isn't already taken by looking in the database.
The methods I've come up with for working with spec are:
- To bind a dynamic variable (*db* for example) containing my database
reference, and have the predicate use that for looking up the email value.
- This loses some locality in my code, and generally suggests a "bad
code smell" in my experience.
- Update the user supplied data to include a reference to the db
- I feel like this complects between the data being validated, with the
information required to perform a validation.
Any suggestions for how I can utilize spec for this scenario?
Dominic
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.
>
>
>
> 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 <javascript:>>
> 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
> <javascript:>
> > 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 <javascript:>
> > 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 <javascript:>.
> > 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.
