On 8 April 2011 08:43, Joost <jo...@zeekat.nl> wrote:
>> What about predicates that operate on numbers encoded as strings? e.g.
>> "1" or "4.2".
>
> IMO, they should be in the strings package.
The strings namespace could get rather large then, considering that
strings are how most raw data is represented.
> Sure, but that's part of the validation mechanism that uses the
> predicates; the predicates all return just true or false. The messages
> associated with that aren't (and IMO, shouldn't) be part of the
> predicates.
I'm not saying they should be.
I'm saying that if a predicate is passed a value that doesn't match a
precondition, the predicate could return a truthy value, rather than
false.
> Basically the problem is one of combining validations (the functions
> that generate feedback); some validations can be "parallel", that is,
> each validation should be run and the messages they return should be
> compounded, but others are dependent on each other, in your example,
> the test for integer-formatting should only be run if the test for
> existence doesn't return an error message.
That's another way of looking at it, and it has a certain neatness and
simplicity to it.
The problem I have with such a scheme is that it seems more complex to
use in practise. For instance, let's say I wanted an optional value.
If predicates that fail a precondition return a truthy value (such as
:pass) I could write:
(defn validate-rating [rating]
(validate rating
[:score integer-string? "must be an integer"]
[:score (between 1 10) "must be between 1 and 10"]))
This would not return an error if the :score field was left blank,
because integer-string? and (between 1 10) would return :pass for an
empty string.
How would you do this in clj-decline?
(BTW, I'm not trying to pick holes in your library - I'm not decided
on Valip's syntax, so I'm curious how clj-decline handles certain
validation situations. It's possible there's a much better way to
approach validation than my current attempts.)
- James
--
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
