commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <>
Subject [cli][Patch] More long only things
Date Sat, 16 Nov 2002 16:03:14 GMT
Hi again,

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

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 :( */

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.

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 " ".

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
  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,


View raw message