On Wed, 2003-03-05 at 12:15, Rob Oxspring wrote:
> ----- Original Message -----
> From: "John Keyes" <[EMAIL PROTECTED]>
> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> Sent: Tuesday, March 04, 2003 10:12 PM
> Subject: Re: [CLI] Version 2.0 - API
>
>
> > > Still, the original poster had a point - isMandatory would typically
> > > return a boolean, whereas setMandatory would be used for setting the
> > > option. In my code, using CLI 1.0, I've been using isRequired(true) to
> > > specify a required option. The true is not necessary, but makes the
> > > point
> > > that I'm setting something, as opposed to getting the value. I think
> > > requiring that usage might make things a bit clearer, perhaps
> > > deprecating
> > > the old methodology.
> > I accept the point that isXXX should return boolean. I will try to
> > think of
> > a better name for the method and also make it take a boolean parameter
> > to emphasize that the method is indeed setting some state.
>
> What's wrong with:
> OptionBuilder withRequired(boolean)
> "with <required> attribute set to <boolean>"
> It sticks with the Builder pattern and doesn't interfere with standard bean patterns.
Not a bad plan, just the readability loses a bit. I think its probably
the best solution so far.
> While we're on the quest for readbility what about:
> OptionBuilder withLongName(String name)
> OptionBuilder withShortName(String name)
> Option create();
> and dropping / deprecating the other create methods. As it stands we look to have
> lost the ability to have long-only options again
> :(
Yeah that sounds like a good idea. Its is possible to create long-only
options, but you need to pass null as the shortName :-( Thanks for
that.
>
> Similar logic would make ArgumentBuilder clearer (to me at least - creating an
> anonymous object
> with a name seems round the twist! :) ). And am I to assume that arguments can't
> really have
> a longName? - it seems to be information that disappears into the
> ether. In fact, is there any chance of some pseudo code to illustrate
> how / why to use arguments? I'm not convinced I've understood where
> they come into play.
Okay the anonymous ones are used for things like goal in maven and
target in ant. The name is used for the HelpFormatter so it
can format this into [target1 [target2...[targetN]]].
An Arugment is anything that requires a value, so for example if
you are using the -buildfile argument for ant you would do the
following:
Argument buildfile = builder.withShortName("f")
.withLongName("buildfile")
.create();
opts.add(buildfile);
...
CommandLine line = parser.parse(opts, args);
String buildxml = line.getValue("-f");
I hope this explains it.
-John K
>
> Thanks,
>
> Rob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
John Keyes <[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
