----- 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.
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
:(
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.
Thanks,
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
