You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by John Keyes <jo...@integralsource.com> on 2002/11/19 23:44:41 UTC
[cli] API change
Hi guys,
The method signature for addValue is currently public, this method
should
only ever be called by the parser when it is creating the command line.
This
method currently returns a boolean when the add fails, this should be
changed
to throw exceptions when a problem occurs.
What is the general consensus for doing something like this? If this
was a
frequently used API then I would say deprecate it, seeing that this was
a
design fault I think it should be okay to change the signature as it
should
not affect any users code.
What do people think?
Thanks,
-John K
- - - - - - - - - - - - - - - - - - - - - - -
Jakarta Commons CLI
http://jakarta.apache.org/commons/cli
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [cli] API change
Posted by John Keyes <jb...@mac.com>.
Martin,
I like the idea you have but as you say yourself there may be
a more elegant solution. I think that this feature is independent
of the API change I recommend as this method was should not have
been exposed in the first place :-(
Log the idea in Bugzilla, so we can keep track of it.
Thanks,
-John K
On 19/11/02 23:58, in article
D1984EE8-FC1A-11D6-A4DD-00039302E230@ucl.ac.uk, "Martin Redington"
<m....@ucl.ac.uk> wrote:
>
> In my own CLI-like library, I've occasionally found it useful to be
> able to hack the command line slightly, before passing it to the
> interrogation phase.
>
> For example, where a parameter two's default value depends on parameter
> one's value, but I don't want to over-write the user's input if they
> specify a value for option two.
>
> in [non-cli] pseudocode ... hopefully you'll get the gist ...
>
> options.addOption("one", defaultValueOne);
> options.addOption("two", defaultValueTwo);
>
> options.parseCommandLine()
>
> // fixupOptions.
> if(options.hasBeenSet("two") == false && "XXX".options.getValue("one")
> ){
> // option 1 was set to XXX, so option 2 should take a different
> default value,
> // unless its already been set.
> options.addValue(alternateDefaultValueTwo);
> }
>
> // interrogate options normally
>
> People probably don't run into this problem a lot, and the above may
> simply not apply to CLI (I haven't ported my apps across from my own
> library yet, or had a chance to have a good look at everything that's
> there).
>
> There may also well be a more elegant or object-oriented solution for
> this kind of dependency between options, and one could always handle it
> during interrogations, but it was useful to me to keep my interrogation
> phase clean, and to isolate the dependencies in a special (and quite
> short) fixupOptions method ...
>
>
>
>
> On Tuesday, November 19, 2002, at 10:44 PM, John Keyes wrote:
>
>> Hi guys,
>>
>> The method signature for addValue is currently public, this method
>> should
>> only ever be called by the parser when it is creating the command
>> line. This
>> method currently returns a boolean when the add fails, this should be
>> changed
>> to throw exceptions when a problem occurs.
>>
>> What is the general consensus for doing something like this? If this
>> was a
>> frequently used API then I would say deprecate it, seeing that this
>> was a
>> design fault I think it should be okay to change the signature as it
>> should
>> not affect any users code.
>>
>> What do people think?
>>
>> Thanks,
>> -John K
>> - - - - - - - - - - - - - - - - - - - - - - -
>> Jakarta Commons CLI
>> http://jakarta.apache.org/commons/cli
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [cli] API change
Posted by Martin Redington <m....@ucl.ac.uk>.
In my own CLI-like library, I've occasionally found it useful to be
able to hack the command line slightly, before passing it to the
interrogation phase.
For example, where a parameter two's default value depends on parameter
one's value, but I don't want to over-write the user's input if they
specify a value for option two.
in [non-cli] pseudocode ... hopefully you'll get the gist ...
options.addOption("one", defaultValueOne);
options.addOption("two", defaultValueTwo);
options.parseCommandLine()
// fixupOptions.
if(options.hasBeenSet("two") == false && "XXX".options.getValue("one")
){
// option 1 was set to XXX, so option 2 should take a different
default value,
// unless its already been set.
options.addValue(alternateDefaultValueTwo);
}
// interrogate options normally
People probably don't run into this problem a lot, and the above may
simply not apply to CLI (I haven't ported my apps across from my own
library yet, or had a chance to have a good look at everything that's
there).
There may also well be a more elegant or object-oriented solution for
this kind of dependency between options, and one could always handle it
during interrogations, but it was useful to me to keep my interrogation
phase clean, and to isolate the dependencies in a special (and quite
short) fixupOptions method ...
On Tuesday, November 19, 2002, at 10:44 PM, John Keyes wrote:
> Hi guys,
>
> The method signature for addValue is currently public, this method
> should
> only ever be called by the parser when it is creating the command
> line. This
> method currently returns a boolean when the add fails, this should be
> changed
> to throw exceptions when a problem occurs.
>
> What is the general consensus for doing something like this? If this
> was a
> frequently used API then I would say deprecate it, seeing that this
> was a
> design fault I think it should be okay to change the signature as it
> should
> not affect any users code.
>
> What do people think?
>
> Thanks,
> -John K
> - - - - - - - - - - - - - - - - - - - - - - -
> Jakarta Commons CLI
> http://jakarta.apache.org/commons/cli
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>