[cli][Patch] More long only things

[Rob Oxspring <ro...@apache.org>]

Hi again,

A bunch of patches, mostly related to long only options.  I've separated
them out to ease the accept/reject process.

OptionGroup: 
Now uses long option as key if short not available.  This allows
multiple long only options to be used in a group.  I prefixed long
options with "--" in line with the "-" for short options although this
only seems to be used by HelpFormatter.  This prefixing seems unecessary
in the light of the HelpFormatter patch, and I would have thought that
exposing the keyset by getNames() isn't that useful.

/* from here on I've been lazy and hand tested only :( */

HelpFormatter:
Factored out appendOptionGroup(StringBuffer,OptionGroup) and
appendOption(..) and appendOptionGroup(..) to allow more consistent
output.  This means that options within a group now display arguments
just as separate options do.  Also changed logic to avoid redisplaying
an option if it's group has been processed.

Parser:
In processArgs(Option,ListIterator) the error message now prefers to
display the long name rather than just the short version of the option.
This was a problem since it was previously telling me of missing args
for option " ".

Options:
optionGroups map now uses long option as a key where the short is
unavailable.  This means that we can have more than 1 OptionGroup with a
long only option.

One other thought: 
The use of short-or-maybe-long options as a map key is an often repeated
pattern in the cli code and it might make sense to move the key building
into the Option class to ensure consistency and declutter the code a
little:
  class Option {
    ...
    public Object key(){
      if(" ".equals(opt) ){
        return opt;
      else {
        return longOpt;
      }
    }
    ...
  }

Btw, what's the rationale behind using " " as the marker for an option
with no short name? To be honest I'm surprised that a String is used
rather than a char anyway but given that, null is surely the natural
choice?  I guess it's a historical thing but I'm curious.

Hope some of that is useful,

Rob

Re: [cli][Patch] More long only things

[John Keyes <jb...@mac.com>]

Hi Rob,

Thanks for these, I'm doing some refactoring around the whole
appending "-" or "--" to the 'key' at the moment.  So when I
have these done I'll get around to checking out those patches.

-John K

On Saturday, Nov 16, 2002, at 16:03 Europe/Dublin, Rob Oxspring wrote:

> Hi again,
>
> A bunch of patches, mostly related to long only options.  I've  
> separated
> them out to ease the accept/reject process.
>
> OptionGroup:
> Now uses long option as key if short not available.  This allows
> multiple long only options to be used in a group.  I prefixed long
> options with "--" in line with the "-" for short options although this
> only seems to be used by HelpFormatter.  This prefixing seems  
> unecessary
> in the light of the HelpFormatter patch, and I would have thought that
> exposing the keyset by getNames() isn't that useful.
>
> /* from here on I've been lazy and hand tested only :( */
>
> HelpFormatter:
> Factored out appendOptionGroup(StringBuffer,OptionGroup) and
> appendOption(..) and appendOptionGroup(..) to allow more consistent
> output.  This means that options within a group now display arguments
> just as separate options do.  Also changed logic to avoid redisplaying
> an option if it's group has been processed.
>
> Parser:
> In processArgs(Option,ListIterator) the error message now prefers to
> display the long name rather than just the short version of the option.
> This was a problem since it was previously telling me of missing args
> for option " ".
>
> Options:
> optionGroups map now uses long option as a key where the short is
> unavailable.  This means that we can have more than 1 OptionGroup with  
> a
> long only option.
>
> One other thought:
> The use of short-or-maybe-long options as a map key is an often  
> repeated
> pattern in the cli code and it might make sense to move the key  
> building
> into the Option class to ensure consistency and declutter the code a
> little:
>   class Option {
>     ...
>     public Object key(){
>       if(" ".equals(opt) ){
>         return opt;
>       else {
>         return longOpt;
>       }
>     }
>     ...
>   }
>
> Btw, what's the rationale behind using " " as the marker for an option
> with no short name? To be honest I'm surprised that a String is used
> rather than a char anyway but given that, null is surely the natural
> choice?  I guess it's a historical thing but I'm curious.
>
> Hope some of that is useful,
>
> Rob
> <roxspring-Parser.patch><roxspring-Options.patch><roxspring- 
> OptionGroup.patch><roxspring-HelpFormatter.patch>--
> To unsubscribe, e-mail:    
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:  
> <ma...@jakarta.apache.org>
- - - - - - - - - - - - - - - - - - - - - - -
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>