commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <>
Subject Re: [CLI] Validation (was 2.x Tasks)
Date Wed, 22 Oct 2003 19:47:30 GMT

----- Original Message ----- 
From: "John Keyes" <>
To: "Jakarta Commons Developers List" <>
Sent: Wednesday, October 22, 2003 7:50 PM
Subject: Re: [CLI] Validation (was 2.x Tasks)

> <snip/>
> > I can definitely understand your thinking but it is a feature I thought
> > quiet handy too.  In the example of DateValidator, checking the string
is a
> > valid date involves the creation of a Date object and it seems silly to
> > throw that instance away when we're only going to recreate it later.  If
> > really don't like the idea of modifying the list parameter I suppose we
> > could change the sig to List validate(List) (Although you should be
> > that at least DefaultOption's process() method modifies it's
> Maybe calling it a Validator is incorrect then.  I had thought
> of changing the method to return a List but then it is no longer
> a validation method, it is a validation and conversion method.

Yeah - the name is stretching the definition a bit.  The loose justification
in my head for DateValidator was "it ensures the values are valid Date
objects" which sounded like validation.

> We could modify the signature as follows:
>     void validate(Option, List)
> The new values can be set on the Option rather than modifying
> the list.

Well it would need a CommandLine parameter too but it would work.

> Or we could define a new interface that extends Validator
> with one method that returns a List (the object instances).
> So validators can implement Validator and validators/convertors
> can implement this new interface (not sure what name to give it).
> To avoid throwing away the newly created objects we could cache
> the results in the validate method and return them via the
> new method.

The word "normalize" has just hopped into my head. Does that cover "validate
and maybe convert" to you?

The caching approach would work but it seems a lot of work to get around a
bad choice of name for the method/class.


> I've started to ramble now so I should stop ;)
> -John K
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message