On Apr 12, 6:35 pm, James Reeves <jree...@weavejester.com> wrote: > On 12 April 2011 12:16, Joost <jo...@zeekat.nl> wrote: > > > An input string of "foobar" is obviously not a number between 10 and > > 20, so whatever predicate you use to test for that should just return > > false. That not everybody here agrees on that indicates to me that > > people are trying to shove too much functionality into single tests/ > > predicates. I want simple, correct, well tested predicates that people > > can use. I'm trying NOT to make design decisions that can be made by > > the user of the library instead. > > I whole-heartedly agree with the sentiment; my only reservation is > that it might make validating form data using those predicates a > little more difficult to use in practise.
For now, I think of the pretzel library as the lowest useful level of abstraction for input tests. And for low level abstractions, I prefer to place a higher value on correctness, extensibility, consistency and possibly even performance (in roughly that order) than ease of use from a direct programmer's stand point. What I mean is that the functions provided should be easily abstracted using macros or higher order functions. There is a danger of making functions "do what I mean" when you also want to have the functions used by other functions; at the very least, it seems to me to expand the contract beyond the easily deduced, making it harder to understand the correctness of the higher level abstractions. > I'm hoping you'll eventually prove me wrong, as your predicates seem > to be the more correct way of doing things. But even if you don't, it > would still make sense for me to base the validation functions in > Valip on the more generic predicates in Pretzel. I'm working on it :) I do think that whatever turns out to be the best solution, bundling obvious predicates into a single library - or a collection of libraries - makes sense. As for your earlier questions on numeric constraints on string values, I think that requires some more thought, at least from me. It doesn't really make sense to have complicated numeric constraints in the strings namespace, if only because it's quite probable people will want to use the same constraints on actual numbers. It might be better to put those predicates in a numeric namespace or library that doesn't address strings at all, maybe relying on a conversion layer somewhere if your input is really string- based, or maybe to have string-based counterparts relying on the numeric tests. I'll be happy to take any suggestions Joost. -- 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
