On Sat, Apr 23, 2011 at 8:36 AM, Matt Benson <gudnabr...@gmail.com> wrote:
> On Sat, Apr 23, 2011 at 6:31 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
>> On Apr 23, 2011, at 7:10, "Jörg Schaible" <joerg.schai...@gmx.de> wrote:
>>
>>> Gary Gregory wrote:
>>>
>>>> Hi All:
>>>>
>>>> I find that the new 'valid' method names in Validate make for odd reading.
>>>>
>>>> I think a verb like 'validate*' or 'check*' would be better. Especially
>>>> when the Javadocs all start with 'Validates...'.
>>>>
>>>> I do see 'check' used in other internal APIs for this kind of behavior.
>>>> For example, Java Swing and Eclipse SWT use 'check*' methods to validate
>>>> state and throw exceptions.
>>>>
>>>> For example:
>>>>
>>>> public void doSomething(String str) {
>>>> Validate.validateIndex(str, 1);
>>>>
>>>> or:
>>>>
>>>> public void doSomething(String str) {
>>>> Validate.checkIndex(str, 1);
>>>>
>>>> The Validate class name is odd too because it is a verb. I would expect
>>>> Validator:
>>>>
>>>> public void doSomething(String str) {
>>>> Validator.validateIndex(str, 1);
>>>>
>>>> A validator validates (or checks) values.
>>>>
>>>> I think I like best the 'check*' methods, probably because I've seen them
>>>> in SWT and Swing for so long.
>>>>
>>>> Thoughts?
>>>
>>> Validator.checkXXX sounds reasonable.
>>
>> I am moving today, so I might not get to this until later. If someone
>> can jump in that would be great.
>>
>
> I think the idea of Validate was to sound "fluently assertive."
> "validate that 'some condition'." I don't find this problematic.
> Conversely, I do find somewhat problematic the idea that [lang],
> arguably the most common of all Commons components, should hijack a
> classname that is already central to not only another Commons
> component, but also multiple JSRs. Let's be kind to our community and
> find another way.
Bit harsh - bear in mind that Validate.java was added in December
2002. Validator was brand new having only released a 1.0 in October
2002 and I suspect the multiple JSRs were either non-existent or being
typically JSR secretive.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
