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

Reply via email to