From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-24 10:12:01
--- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> From: bill_kempf [SMTP:williamkempf_at_h...]
> >
> > --- 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?
It doesn't. In fact I explicitly stated that I didn't think it
should ;). I was merely pointing out the huge flaw in thinking that
we could just settle on Unix style short and long options and ignore
every other style that exists. I've strongly disagreed with making a
single choice (Unix/DOS/some other variant) from day one. It should
be configurable by the developer, and optimally the library should
have a "default" the follows the conventions of the platform it runs
on. I realize the final part of that last sentence is probably not
likely to be possible, but that is the optimal design.
Bill Kempf