On Tue, Apr 12, 2011 at 8:05 AM, James Reeves <jree...@weavejester.com> wrote: > On 12 April 2011 12:02, Ken Wesson <kwess...@gmail.com> wrote: >> Don't be ridiculous. If you're putting that (chain ...) sexp of yours >> in every separate place where a field is checked for being an integer >> in a range, then that's duplication. And if you extract it into a >> function that just takes the endpoints as parameters (and maybe the >> error strings, or a map of these), then you have a compound function. > > I think our differences lie in when that compound function is constructed. > > My opinion is that you should only combine your validations when you > are certain of all the parameters. Because only the end developer > knows what messages should be used, it should be the end developer's > responsibility to combine those validations.
That's silly in a number of common cases. For example, it will be very common to need a field to be an integer within a certain range. So it makes sense for the library to provide a single function for that very common case instead of every app developer having to reinvent the "check it's not blank, check it's not non-integer, check it's not low, check it's not high" wheel over and over again. > In your case, you're combining your validations *before* you know what > the messages are, so your validation function then needs to be > combined with an external map of error message. So? I'm factoring out the logic that is common to all applications and leaving the application-specific details as parameters. > Both approaches amount to the same thing, but I prefer the former > approach. And I don't. I don't want to have to compose everything from ultra-primitive bits from scratch. If I did I wouldn't use a third-party library. In fact I'd probably code in ASM instead of Lisp. > It makes sense (to me) to combine functions only when they > can be said to contain a combined purpose (e.g. to define the valid > values of a particular type of object). And combining "is not empty" and "is an integer" with "is an integer in a certain range" is NOT a "combined purpose"?! >>>>> In my experience, "deny-by-default" is the right answer in >>>> >>>> less than 100% of cases. >>> >>> I didn't say that. >> >> Yes, you did. > > If you're going to be childish, I don't think we should continue this. If you're going to be childish, I don't think we should continue this. > I have not deliberately misinterpreted anything you have said. Then you must be one of the most accident-prone people on the planet. :P > You don't seem to disagree that deny-by-default is the most secure > scheme in most scenarios Oh, but I do. "Most scenarios" are not large, mission-critical multi-user net-facing systems. "Most scenarios" are single-user personal software, internal-use-only stuff used by a small trusted group (e.g. internal tools used by a game company's 3 level designers), or one-offs for individual, personal use. > so I'm uncertain why you think this wouldn't be a sensible default. We don't NEED "a sensible default" when anyone designing something should know before they write a single line of code whether it's going to be big and either net-facing or many-user! > At this point, I don't believe we'll reconcile our differences, and > your tone is becoming just a touch hostile. MY tone? You're the one who keeps coming back every couple of hours with a post full of innuendos that I'm in some way wrong, silly, or deficient. So far, you're the only one to have brushed close to engaging in name-calling in this thread (having twice said something about me was "strange"). > Let's end the discussion here. Fine. -- 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
