On Mon, Apr 11, 2011 at 3:09 AM, James Reeves <jree...@weavejester.com> wrote: > On 10 April 2011 22:24, Ken Wesson <kwess...@gmail.com> wrote: >> On Sun, Apr 10, 2011 at 1:37 PM, James Reeves <jree...@weavejester.com> >> wrote: >>> By adding error messages to predicates, we tightly couple the >>> validation error with the predicate, which in general is considered >>> bad. However, this might be a valid compromise, but only if it >>> improves readability. >> >> I showed two posts ago how to keep that decoupled. > > You decoupled the validation message (e.g. "age is required") from the > validation error (e.g. :blank), but validation error is still tightly > coupled to your predicate.
Of course it is. Blank is blank. > Putting it another way, I can represent this code: > > (age-invalid-en (not-int-in-range? age 1 120)) > > With four separate predicates: > > (validate thing > [:age present? "age is required"] > [:age integer-string? "age must be a whole number"] > [:age (at-least 1) "age must be at least 1] > [:age (at-most 120) "nobody is that old"]) > > So your not-int-in-range? function is a compound function, made up of > four simple functions. So? This whole discussion arose because some of them have preconditions, like at-least 1 not making sense for blank or non-integer input. >> I think it's a bit subtler than that. On the face, I wouldn't disagree >> with that statement. But if you arrive at your security rules by two >> different procedures, one resulting set of rules might specify >> what-to-deny and be more secure than another that specifies >> what-to-allow. > > That's possible, but is there anything that indicates the predicates > I've used so far are less secure than the validation functions you've > used? Is there anything that indicates they're more secure? >> And ultimately there's a mathematically equivalent >> what-to-allow set for any what-to-deny set, and vice versa, like a >> photograph and its negative. > > But if people are used to creating photographs, why change it around > so they have to use the negative? If people are having a problem with the existing way, it's useful to suggest alternative ways of looking at the problem. Here, for instance, there was some difficulty regarding preconditions, and generating the right error message when more than one thing failed (e.g. it wasn't in the range 1 to 120 because it wasn't an integer at all). I just thought it might be helpful to look at things from another direction. Now we can all look at things from *both* directions. -- 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
