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 18:12:38 GMT
----- Original Message ----- 
From: "John Keyes" <>
To: "Jakarta Commons Developers List" <>
Sent: Wednesday, October 22, 2003 5:10 PM
Subject: Re: [CLI] 2.x Tasks

> <snip/>
> > 1.3) Enum Argument Values
> >
> > Options should allow a list of possible values to validate against.
> > Currently this is in StringValidator but would EnumValidator be better
> > StringArrayValidator is also a suggested name.
> >
> >
> >
> I have renamed the StringValidator.
> We should not modify the List that is passed to the validate
> method.  It can lead to behaviour not defined by the API e.g.

But we could define the behaviour with a few comments :)

> (taken from DateValidatorTest):
>     final Object[] array = new Object[] { "23/12/03", "2002-10-12" };
>     final List list = Arrays.asList(array);
>     validator.validate(list);
> This will actually modify 'array' (see Arrays.asList).  This smells.

I can definitely understand your thinking but it is a feature I thought was
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 you
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 aware
that at least DefaultOption's process() method modifies it's ListIterator).

> I think we should leave the Validator as is and not
> perform any instance creation.  In CLI 1 there was
> an optional type attribute for Arguments
> (java.lang.Class).  The value of an Argument could
> be retrieved using two different methods:
>    CommandLine.getOptionValue : String
>    CommandLine.getOptionObject : Object
> The getOptionObject created the relevant instance from
> the string value.

The way I see it is that for any given option you either want it as a String
or an Object.  If your validator has checked you have a valid Date or Number
then I can't see why you would ever want to get to the original String
version back rather than the richer objects.  I've got no objection to a
convenience method performing the common cast-to-String, but I don't see the
need to delay the transformation until the interrogation phase.


> I think we should use a similar mechanism now.
> -John K
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message