Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <003a01c4ff57$2915f900$a80b8451@SCOLEBOURNE>
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
References: <41EF9702.5080502@telus.net>
Subject: Re: [lang] lang.Validate
Date: Fri, 21 Jan 2005 01:18:45 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

The Validate class is intended to be used to validate entry to methods at 
runtime, similar to the assert keyword in JDK1.4. It is not intended to be a 
general purpose validation class.


> What I'm wondering is, are there are any plans to increase the scope of 
> Validate's tests?  And if there aren't any such plans, would the 
> maintainers be open to someone else (me, for example) submitting patches 
> that expand the functionality of Validate?

There are no plans at present. Specific ideas are welcomed, as are patches. 
Patches should be submitted to bugzilla with test cases using the correct 
patch format (see pages on website)


> I can think of quite a few tests that could be standardized by Validate. 
> For example:
> A regex matching test; Validate.matches(param, "[1-9][0-9]*");
> A numerical range test; Validate.inRange(param, new IntRange(0, null));
> A test for asserting a predicate over an array collection:
> Validate.forAll(myList, myPredicate);
> Even a simple nonNegative test for the integral and floating point 
> primitives would be great.

Any enhancement suggestions will be judged based on whether they fit the 
intent of the class, and whether they are JDK1.2 compatible (regexp isn't 
for example).

Of your suggestions, I believe that numeric range validations could probably 
be added, but regexp and predicate based classes would not.

I also suggest discussing particular proposals before going to the effort of 
implementation.

Hope this helps.
Stephen


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