Return-Path: 
 <commons-dev-return-38904-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 82299 invoked from network); 22 Oct 2003 18:12:51 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 22 Oct 2003 18:12:51 -0000
Received: (qmail 20630 invoked by uid 500); 22 Oct 2003 18:12:37 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 20575 invoked by uid 500); 22 Oct 2003 18:12:37 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:commons-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 20523 invoked from network); 22 Oct 2003 18:12:37 -0000
Received: from unknown (HELO out2.smtp.messagingengine.com) (66.111.4.26)
  by daedalus.apache.org with SMTP; 22 Oct 2003 18:12:37 -0000
Received: from mail.messagingengine.com (localhost [127.0.0.1])
	by localhost.localdomain (Postfix) with ESMTP id B38F43346AA
	for <commons-dev@jakarta.apache.org>; Wed, 22 Oct 2003 14:12:39 -0400 (EDT)
Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by
 messagingengine.com
  with SMTP; Wed, 22 Oct 2003 14:12:39 -0400
X-Epoch: 1066846359
X-Sasl-enc: j3Ims833uWltGbKUOlfbmA
Received: from fry (cpc2-oxfd2-4-0-cust57.oxfd.cable.ntl.com [62.254.143.57])
	by www.fastmail.fm (Postfix) with ESMTP id 0DF60336095
	for <commons-dev@jakarta.apache.org>; Wed, 22 Oct 2003 14:12:39 -0400 (EDT)
Message-ID: <006c01c398c8$14fef440$398ffe3e@fry>
From: "Rob Oxspring" <roxspring@imapmail.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: <004f01c398a7$82f572b0$398ffe3e@fry>
 <1066839053.1447.52.camel@oasis.capeclear.ie>
Subject: Re: [CLI] Validation (was 2.x Tasks)
Date: Wed, 22 Oct 2003 19:12:38 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

----- Original Message ----- 
From: "John Keyes" <jbjk@mac.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
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
name?
> > StringArrayValidator is also a suggested name.
> >
> >
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=102750803811805&w=2
> >
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103951380212779&w=2
>
> 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.

Rob

>
> I think we should use a similar mechanism now.
>
> -John K
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


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