I just pushed [bouncer "0.2.2-RC1"] - would appreciate if you could give that a go.
You can check the changelog to see what's new: https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md#022-unreleased But the big changes include: - a qualified keyword for the errors entry and; - a short-circuit mechanism as suggested by Gary If everything looks good or I don't hear back, I'll push 0.2.2 final to clojars tomorrow and send a full ANN post. Cheers and thanks for the great feedback. Leo. Leonardo Borges www.leonardoborges.com On Fri, Jan 11, 2013 at 10:35 AM, Leonardo Borges < leonardoborges...@gmail.com> wrote: > Hi Gary, > > First off, I wanna thank you for you thorough review and feedback of > bouncer - it's very much appreciated. > > Please see my comments inline. > > > On Fri, Jan 11, 2013 at 2:35 AM, Gary Johnson <gwjoh...@uvm.edu> wrote: > > Also, I agree with Stathis that there is a problem including the errors > map > > in the original data structure under an unqualified keyword. Of course, > if > > you change validate to not modify the input map that is being validated, > > then you no longer need a state monad to model the validation workflow. > This > > could just as easily be done with a simple reduce. In this instance, I'd > > guess that just qualifying the ::errors keyword would probably stick > closest > > to your original model. Maybe I'm totally missing the mark here though. > > > > Sold. You're the second person to mention this so I believe it's worth > considering. > > My original thinking was to use the errors key as a convention for > validation errors but > given the multitude of domains this could be applied to, that might > have been a bit too selfish. > > I'll add a qualified error keyword to the next release. > > > > > So basically what I'm suggesting as an enhancement to your library is > that > > whenever a field is being tested with a multi-validator vector, the first > > test to fail should prevent any other tests (to its right in the vector) > > from running. This would be similar in spirit to the behavior of the -?> > and > > -?>> thread-maybe macros in clojure.core.incubator. > > > > This makes sense. Thanks for the code snippets - they illustrated your > point brilliantly. > > The current design shifts that onus to the validators and in cases > such as the one > demonstrated by your second code snippet, this is far from ideal. > > I've put your code in the test suite which means I now have a broken > build I need to fix :) > > This would be a great addition to bouncer. I'll take some time to go > over a couple of implementation > options but I'm keen on adding it in. > > > Okay, constructive criticism and all that aside, great work on this > library > > again. Looking forward to the next release soon. > > > > ~Gary > > > > I'm glad you enjoyed the lib - stay tuned, I'll probably have news > over the weekend. > > Cheers, > Leo. > -- 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
