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 [EMAIL PROTECTED], "Martin Redington" <[EMAIL PROTECTED]> 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: >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> >> >> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
