RE: [boost] Re: Command line syntaxes

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-24 08:05:35

From:	bill_kempf [SMTP:williamkempf_at_[hidden]]
> 
> --- In boost_at_y..., "Schoenborn, Oliver" <oliver.schoenborn_at_n...> 
> wrote:
> > > Schoenborn, Oliver wrote:
> > > >
> > > > Sorry if this has already been explicitly ruled out, but is 
> there a
> > reason
> > > > for not distinguishing between long and short arguments by 
> using - for
> > > > short and -- for long?  
> > > 
> > > I find it the best syntax. In fact, this is what you get with the
> > predefined 
> > > "unix" style. However, people was asking for long options names 
> with a
> > single 
> > > dash/slash. 
> > 
> > Yes, but just because users ask for it doesn't mean it is a good 
> feature to

This is important to any design.

> > without sacrificing true versatility? I suspect that only a very 
> small
> > minority of users would need the long options with one '-' so bad 
> that they
> > would refuse to use the boost command line library.
> 
> I don't agree.  Using two sets of switch charaters with two distinct 
> sets of command line options will just confuse most users, and serves 
> no purpose when "long options" require only as many characters as 
> required to distinguish it from other "long options".  The use of 
> multiple switch characters is actually what I find most annoying of 
> Unix style command line parsing.  If a command line parser must pick 
> a single way to parse (I don't agree that it should) then I'd 
> strongly argue for '/' or '-' denoting the beginning of an option, 
> with the option matching any subset of charactes in any of the valid 
> options that reduces to a single choice, and other options/arguments 
> would then be required to be seperated by white space.
> 
> I bet many people would agree with me... especially those from non-
> Unix backgrounds.  I'd be surprised if the numbers that agreed 
> represent a "small minority" of users (especially if you include 
> actual users and not just programmers).

Why must the CLL force one or the other?  An option could be specified as
long or short, the library user could specify the delimiters to use for long
and short options, and the rest would "just work." True, this doesn't
account for long options with either "--" or "-" delimiters, but I doubt
there are any applications that require both. If there were, then the CLL
could even allow the client to specify a set of delimiters for long and
short options. That would allow for "-" and "+" for short options as well.

Clearly, for that to work, the CLL would need to indicate which delimiter
was found together with the option name and value, if any. That allows the
client to decide how to do the assignment. For example, "-" and "+" set, or
reset, respectively, the corresponding option. In general, however, there
should be a policy class function that determines how to assign values based
upon the delimiter. Thus, the CLL defers to the policy class to do the
assignments, which can, in turn, take advantage of standard mechanisms
supplied with the CLL.

Policy decisions should always be pushed as high as possible without pushing
them too high. The choice of delimiters can easily be put into a policy
class. Thus, those writing a DOS app can provide the DOS policy class and
get case insensitive options that only use "/" as the delimiter. Those
writing a Unix app can provide the Unix policy class and get case sensitive
options that use "-" and "+" for short options, and "-" and "--" for long
options. Furthermore, developers can create their own policy classes that do
things differently still.

One thing that I've found necessary recently, that hasn't been addressed in
these discussions, is the ability to split the command line. We have a
scenario in which two parts of the application, one of which we have no
control over, require command line arguments. We have adopted "@" as the
separator between the command line arguments for the parts. Thus, what
precedes "@" is given to one part, and what follows "@" is given to the
other part. Fortunately, the second part doesn't need a valid argv[0], so we
actually pass "@" as argv[0] to it. Still, the CLL could offer the ability
to specify one or more delimiter for splitting the command line. Once split,
the CLL could process one part at a time, under application control. That
means that the command line should be tokenized into some sort of collection
which can be given to the application for subsequent return. (This could be
done via the Memento Pattern to keep the data opaque.)

Rob
Susquehanna International Group, LLP
http://www.sig.com