commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [lang] Validate, method names, class name
Date Sat, 23 Apr 2011 15:36:44 GMT
On Sat, Apr 23, 2011 at 6:31 AM, Gary Gregory <garydgregory@gmail.com> wrote:
> On Apr 23, 2011, at 7:10, "Jörg Schaible" <joerg.schaible@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.

Matt

> Gary
>
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message