commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keyes <j...@mac.com>
Subject Re: [CLI] some thoughts
Date Wed, 14 Aug 2002 23:31:24 GMT
Berin,

I have commited the changes.  Please give them a whirl and let me
know if you have any problems with it.

Use the iterator() method on CommandLine to give you a java.util.Iterator
over each processed Option.

Cheers,
-John K

On Wednesday, August 14, 2002, at 01:39 , Berin Loritsch wrote:

> I like the work you've done with it, so I am +1.
>
>> -----Original Message-----
>> From: John Keyes [mailto:jbjk@mac.com]
>> Sent: Tuesday, August 13, 2002 7:44 PM
>> To: Jakarta Commons Developers List
>> Subject: Re: [CLI] some thoughts
>>
>>
>> Guys,
>>
>> There is another casualty of following the approach I have
>> taken.  As the call to Options.getOption( ) now returns a
>> clone of the Option rather than the Option itself the
>> following style is not possible:
>>
>> Option j = OptionBuilder.create();
>> options.addOption( j );
>> CommandLine line = parser.parse( new String[] { "-j",
>> "jvalue" } ); // this will print null System.out.println(
>> j.getValue() );
>>
>> I don't think this is too common an approach that will be
>> taken anyway, but it is slightly annoying.
>>
>> I am still +1 on going ahead with the current approach.  If
>> anyone has a problem please holler before this time tomorrow
>> coz I am hoping to get this stuff tidied up and commited then.
>>
>> Cheers,
>> -John K
>>
>> On Monday, August 12, 2002, at 09:46 , John Keyes wrote:
>>
>>> I have been mucking about with some changes that would
>> reflect some of
>>> the ideas Berin has mentioned over the last couple of weeks.
>>>
>>> I do like this new model of processing Options but I would like to
>>> also maintain the previous model as I like the idea of the
>>> flexibility.
>>>
>>> So from my experiments I can support the current API and
>> also support
>>> the new style suggested i.e. the Avalon approach.
>>>
>>> The only casualty of this change is the withArgs( int )
>> method, which
>>> allows the user to specify the number of arguments that an
>> Option can
>>> have.  This feature was only added last week and I added it
>> because I
>>> misunderstood the request from Berin for support of the
>> property style
>>> Option values.
>>>
>>> The withCharSeparator method on OptionBuilder can support this.
>>> Instead of using withArgs( int ) the withCharSeparator can
>> be used to
>>> exclusively process these properties.  The default char
>> separator is
>>> '='.  This can be changed for path properties ':' or ';'.
>>>
>>> The new implementation would also mean the code that splits
>> the option
>>> values now resides in the Option as opposed to the
>> individual parsers.
>>>
>>> When this is complete I think we are set for a beta release.
>>>
>>> -John K
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:   <mailto:commons-dev-
>>> unsubscribe@jakarta.apache.org>
>>> For additional commands, e-mail: <mailto:commons-dev-
>>> help@jakarta.apache.org>
>>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
>> For
>> additional commands,
>> e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>>
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
>


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


Mime
View raw message