When you state a function you bind it already to an implementation, in fact to a specific function from a specific ns.
While for simple functions its not that bad, things start to get hairy when you manage a large number of custom validations also using just string? leaves out metadata (like error messages etc..) What Iv found after using a couple of existing frameworks is that id like to be able to define and compose validations declarations in a simple and clear manner with little ceremony. In a lot of cases there is a base of validation that is common to a number of entities, they differ in some parts but there is a lot of duplication. Its also very hard to follow a large number of validation if the structure of the definition is to far off from the structure of the input. I think that going through this ns<https://github.com/celestial-ops/celestial-core/blob/master/src/vc/validations.clj> showcases some of these points, we have two maps to validate: - An entity, persisted into data store - A model which is used against a third party. Both are quite similar but still different enough, hope it makes my points clearer. Thanks On Saturday, July 27, 2013 10:23:17 PM UTC+3, Ben wrote: > > Why not just use functions for the validations? string? instead of > :String. Then you get disjunction for free. > > > On Sat, Jul 27, 2013 at 12:22 PM, ronen <nar...@gmail.com <javascript:>>wrote: > >> >> Thanks for the feedback! >> >> Hi, >>> >>> Some feedback and questions, as I've made something similar in the past. >>> - allow normal fns and classes as a predicates. >>> >> - having one global Var for predicates is an antipattern >>> >> >> The Var is only for the built in ones and is internal and private, >> external ones are stored in an atom, if you have better alternative id >> be happy to hear. >> >> >>> - can you compose predicates logically (AND/OR)? >>> >> >> If you mean something along the lines of {:foo #{(or :String :Integer)}} >> then no, in that case I would suggest defining a new validation and use >> that: >> >> (validation :int-or-str (when-not-nil #(or (string? %) (number? %))) >> >> The predicates have implicit AND relation by default. >> >> >>> - can you validate a contents of the vector? >>> >> >> You can write a predicate that goes through a vector and asserts its >> values, there no special support for asserting special positions, do you >> have an example? >> >> As an inspiration, the validator I'm using allows for following rules, >>> which IMHO looks a bit cleaner: >>> >>> >> Your using classes which is indeed useful for the basic types, however it >> complects description with implementation which is what I wanted to avoid, >> >> Nothing for example stops me from taking the description that I use and >> move it to clojurescript (which java classes prevents) >> >> Hope it makes sense >> >> >>> (defn- uri? >>> "Checks if input is valid URI." >>> [uri] >>> (try >>> (URI. uri) >>> true >>> (catch Exception e false))) >>> >>> (def location-rule {:name String :lat Number :long Number}) >>> >>> (def contributor-rule {(required :id) uri? :gender #{"m" "f"} >>> :birthDate String >>> :locales [String] :homeAddress location-rule}) >>> >>> Best, >>> Jozef >>> >>> >>> On Saturday, July 27, 2013 5:50:14 AM UTC+2, ronen wrote: >>>> >>>> Substantiation is an opinionated simple nested map validation library: >>>> >>>> - Predicates and description kept separate. >>>> - Validation description map follows validated input structure. >>>> - Pure data structures to describe validations. >>>> - Composability of validations is trivial. >>>> - Validation predicates scope is limited (can only access the >>>> checked value). >>>> - High level decisions such as when to activate a group of >>>> validations should happen on upper layer. >>>> - Non strict, only described items checked. >>>> >>>> Github: >>>> https://github.com/narkisr/**substantiation<https://github.com/narkisr/substantiation> >>>> >>>> Feedback is welcome >>>> Ronen >>>> >>> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Ben Wolfson > "Human kind has used its intelligence to vary the flavour of drinks, which > may be sweet, aromatic, fermented or spirit-based. ... Family and social > life also offer numerous other occasions to consume drinks for pleasure." > [Larousse, "Drink" entry] > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
