commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@imapmail.org>
Subject Re: [CLI] Version 2.0 - API
Date Wed, 05 Mar 2003 12:15:18 GMT
----- Original Message -----
From: "John Keyes" <jbjk@mac.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message