On Tue, Apr 12, 2011 at 6:34 AM, James Reeves <jree...@weavejester.com> wrote: > On 12 April 2011 04:31, Ken Wesson <kwess...@gmail.com> wrote: >> There's a difference between the program parsing the same *object* >> multiple times, and the program's own source code containing >> duplication! > > But there isn't any duplication
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. > > (defn present? [x] > (not (string/blank? x))) > > (defn- parse-int [x] > (try (-?> x Integer/parseInt) > (catch NumberFormatException _ nil))) > > (defn integer-string? [x] > (boolean (parse-int x))) > > (defn over [n] > (fn [x] (-?> (parse-int x) (> n)))) > > Unless you're asserting that calling parse-int twice is code duplication? Way to not see the forest for the trees. That level isn't where the duplication is. It's at the level that calls these, or the level above that. >> Actually, nil is returned. And you're cheating. Your "validate" >> function is presumably as complex. The same information ends up in its >> docstring, or distributed among present?, email-address?, and the >> like. > > But as a developer who is using the API, why should I care what > validations the "validate-user" applies, so long as those validations > are correct? What? Now you're confusing the layers again. Presumably validate-user takes a structure and applies predicate tests and potentially generates error messages. That puts it at the same level as the *caller* of my not-int-in-range? function. So if you're comparing that with your validate-user, you're comparing apples and oranges. > We seem to have different ideas about what complexity is at this > point. No, just about *where* it is. And the difference seems to stem from confusion on your part that I'm beginning to think may even be intentional, sadly. >> And any function that validates range-limited integer inputs ends up >> checking the same four things. > > Yes, but not necessarily in a divisible fashion. Define "divisible"? The in-range check depends on there being an integer. The integer check depends on the field not being blank. The in-range check thus can't be "divided out" more than I've already done. Unless you make it the calling layer's responsibility to check for blank and for non-integer first, and that way lies that code duplication again, as the same pattern of sequential check-and-branch logic repeats everywhere where an integer has to be in some range. >> I was not. I only claimed that forgetting anything *could* cause a >> security risk, depending on the system. > > Looks like I misinterpreted you, then. For some odd reason that seems to be happening a lot lately. >>>> But, but, but. You made a universal statement that I've proven was >>>> wrong. You've basically admitted this by admitting that there are any >>>> exceptions at all to your "universal" rule. So, why keep arguing? >>> >>> What universal statement are you talking about? >> >> You made a blanket claim that deny-by-default is superior. > > Now you're misinterpreting me :) No I am not. > There may conceivably be a situation where deny-by-default is less > secure than allow-by-default. However Well, that makes a *slight* change from "But". >> You're viewing it the wrong way. Once a new owner takes possession of >> the device, that new owner should decide its policy. If the old >> owner's policies keep intruding after that point, that's unauthorized. >> The new owner *should* be able to obliterate and replace any such >> policies. If they cannot, the dead hand of the old one has in effect >> intruded. > > That's a very strange definition of what unauthorised access constitutes. Now you're just going around in circles. I think we're just about done here. >>> In my experience, "deny-by-default" is the right answer in >> >> less than 100% of cases. > > I didn't say that. Yes, you did. > In any case, I don't understand your objection. You don't have to understand it. You just have to stop arguing around in circles. > If you accept that in the majority of cases, deny-by-default is the best > choice, > then surely it's the best default security policy? For network-facing and/or multiple-user mission critical systems, yes. But its costs tend to outweigh its benefits for single-user personal devices and software in a lot of cases. -- 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
