Re: [boost] Re: program_options lib review

From: Tanton Gibbs (thgibbs_at_[hidden])
Date: 2003-05-23 00:04:44

> I understand why you might need additional parsers. The important point
> about them is that it's easy to add them. Since the parsing part is
> hidden behing the "parse*" functions, to add a new parser one would need
to
> only to add "parse_xml_config_file" function. Probably some of such
> functions must be added to the library --- but that depends on user
> feedback.

Ah, I guess I misunderstood.  I thought the parse* functions were just for
the command line.  Since that is not the case, then my concerns over that
are alleviated.  It would be nice to provide some common ones (name=value,
winini, environment vars, etc...)
>

> > Here are my addressable comments
> > (1) I would like to have a find_if and count_if function as I often want
> > to
> > find a parameter of the format *.field.*  It doesn't matter what the *'s
> > are
> > as long as it contains .field.  They should both take a function as a
> > parameter.
>
> Those functions should be added to variables_map, right?

correct.

> > (2) Someone else mentioned custom parameter verification.  I'm kind of
> > split
> > on this.  I don't mind it if you could pass in an arbitrary functor
(like
> > a
> > lambda library functor).  However, I also don't mind doing the
validation
> > outside of the library.  I definitely don't want the parameter function
to
> > take arbitrary parameters (like the min/max idea presented earlier) as
> > that would just be too confusing.
>
> I think 'parameter' function should not take arbitrary parameter, or we'll
> be lost in overloading ambiguities. However, user or I can write more
> functions, similiar in spirit to 'parameter', but with added semantics.
> E.g:
>
>    desc.add_options()
>         ("compression", range_parameter("n", 1, 9), "desired compression")
>         ;
>

I would rather see something like
      desc.add_options()
          ("compression", parameter("n", (_1 >= 1 && _1 <= 9)), "desired
compression")

I think that is infinately more flexible.  There is no possible way you
could imagine how people want to validate.  However, if you wanted, you
could provide shortcuts.
      desc.add_options()
          ("compression", parameter("n", in_range(1, 9)), "desired
compression" )

If you really did not want the extra argument to parameter, then you could
tack it on like default_value.
      desc.add_options()
          ("compression", parameter("n").validate( in_range(1, 9) ),
"desired compression" )

> > (4) What if I want parameters to occur in a particular order?  For
> > example, the -kk option can only occur after the update parameter in
cvs:
> > cvs update -kk blah blah blah is legal
> > cvs -kk update blah blah blah is not
> > It would be nice to either be able to specify a mandatory ordering, or
to
> > be
> > able to find out the position of the parameter.  If you could specify a
> > mandatory ordering, then I would like it to be relative.  For instance
> > every parameter with ordering level 0 must appear before every parameter
> > with ordering level 1; however, parameters with ordering level 0 can
> > appear in any order amongst themselves.
>
> Something like that could be added, but I'll try to do that only if
> seriously pressed by some user. The reason is that I find such command
line
> syntax to be confusing. As I've mentioned some time ago, in CVS the same
> option means different things depending on position and this leads to user
> confusion, not convenience.

I understand this and won't quable over it.  It definately has its
downsides, but there are programs that use it and it would be nice to say
the lib supports it.  And, FWIW, I still have trouble with cvs command lines
:)

Tanton