On Sun, Nov 29, 2009 at 3:26 PM, Stephen Colebourne <scolebou...@btopenworld.com> wrote: > Paul Benedict wrote: >> >> I want to rename isTrue to validateArgument (which throws >> IllegalArgumentException); then also introduce validateState (which throws >> IllegalStateException). > > We have this in a work version of this class, I'm not sure that it doesn't > confuse the purpose of the class. As such, I think I'd prefer a second State > checking class, so this one is solely argument checking.
Stephen, I did not see anything that indicates this class is purely for argument checking. Granted, the usage is geared towards it, but I don't think this class needs to be limited to such. Do you have any suggestions that could go into the State checking class? I think adding a validateState method is simple and fits in line with all other checking logic thus far. Often it's an API violation to call a method at the wrong time --- the wrong time being a failure of some boolean logic. >>> I also propose we rename the methods so that the verb "validate" prefixes >> them all (Google Collections uses "check"). Furthermore, this will better >> namespace the method when static imports are used: >> isTrue -> validateArgument / validateState >> notNull -> validateNotNull >> notEmpty -> validateNotEmpty >> notBlank -> validateNotBlank >> validIndex -> validateElementIndex >> noNullElements -> validateElementsNotNull >> >> I also want to introduce some new methods: >> validateInstanceOf >> validateAssignable > > I'm not sure I buy static imports here. They are no shorter than the > original Validate.notNull (well one character shorter). > > If we are renaming, I'd suggest > Validate.noNullElements -> Validate.noNulls > The purpose of the renaming was to give them verbs. Seeing "validateNotNull" is clearer than "noNulls". It's not about being shorter; my focus is on readability. I prefer methods do (verb) something. After all, JUnit "assert"s conditions, Google Collections "check"s conditions, can't Apache Commons "validate" conditions? Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
