On Sat, Apr 9, 2011 at 9:56 AM, James Reeves <jree...@weavejester.com> wrote: > On 8 April 2011 23:21, Ken Wesson <kwess...@gmail.com> wrote: >> Better yet: maybe we're looking at this backwards. Maybe what we want >> isn't a predicate for *passed* validation, but a predicate for >> *failed* validation: >> >> (defn s-blank? [x] >> (if (empty? (.trim x)) "must not be blank")) > > That particular example ties a predicate to a particular error > message. Error messages should be independent of predicates, otherwise > they can't be localized or changed to fit a specific situation.
It can always be an integer or a keyword (or a string!) used to look up the localized or situation-specific message in a map. >> This takes advantage of the fact that the error messages we want are >> all "truthy". It's also the case that you often want to detect and >> handle invalid input right away, then get to the meat of the logic. >> The natural ordering of if, if-let, etc. puts the "true" case first. >> Making the "true" case the error case lets you easily get it out of >> the way first in your code. > > This would lead to a lot of validations with "not" in front of them. > i.e not-email-address?, not-integer?, etc. So? -- 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