RE: [boost] Re: Preliminary submission: command line & config fil e library

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2003-01-15 13:01:11

> There are only syntactic differences with
>    
> http://zigzag.cs.msu.su:7813/program_options/html/variables_map.html

No. I don't think so. You present fixed rigid interface. In my case almost
everything is optional. You don't have parameter description - you don't
provide one.
On the other hand with my interface end-user( programmer) could introduce
his own parameters and modifiers types within bounds if existent framework.

> 
> However, some of them are important for me. I'd like to have as little
> typing as reasonable, so
> 1. "cla::named_option" is extra typing for a very common case

I believe that in this specific case (cla) expressiveness is mush more
important than conciseness. After all it only defined once in program. My
cla parameters could have a lot of "features": optional/required,
multiplicable, default_value, ..... And presenting them just as true, 5,
true, my_var ... is unclear IMO. Especially if you returning to the program
that you wrote year ago and trying to find what is going on with command
line arguments. SO in other words I prefer human readable format for
parameter definition to concise "binary" one.

> 2. "cla::required" is extra typing for a very common case.

In fact it's optional. all parameters are required by default. Presented
only for example.

> I've tried to make such common case as simple as possible:
> 
>     options_description desc;
>     desc.add_options()
>     ("foo", "arg", "interesting option")
>     ("bar", "arg?", "another one")
>     ;
> 
> I really think that the "arg?" notation is superior to any use

Now you need to remember what mark "?" mean. And what is the type of it? IMO
much better more expressive:

named_argument<int>( arg ) << cla::optional

BTW what if I want ? as a part of my parameter name?

For example:

my_program /roll trace file? = "yes"

CLA is basic facility that is used by many people with different habits. You
could not afford to incur too many restrictions.

> Say, I'm writing a generally-useful module. Unfortunately, 
> it has about 40
> options, which should be customizable by users. With your 
> design the module
> would add those options to the global parser. How to use the 
> module inside
> other application? The parser has different lookup policy, 
> and the code which
> adds options no longer works.

I did not mention that, but I do have support for this usage scheme. You may
see that method parse accepts it's argument by reference. As a result after
parsing is complete and mismatches are ignored argc/argv contains unparsed
part of program input. that you could supply to the different parser for
example. This way you could make chain of parsers each responsible for each
own parameters.

> > Argument access.
> > 
> > The framework provide several ways to access the parsed 
> argument values
> > 1. Through first_argument/last_argument interface. It will 
> work if parameter
> > will create typed formal argument (inherited from 
> typed_argument<T> )
> >    It will look like this:
> >    cla::parser<...>::iterator it = parser.first_argument();
> >    cla::argument* arg = *it
> >    long value = cla::get_value<long>( arg  );
> 
> What happens if no type is declared for this value? How 
> get_value works?

It does not. If argument does not support typed_argument interface it should
provide different means to the value access. it's up to the argument class
designer and is not forced by the framework.
 
> > 3. Most parameter types supports cla::handler modifier that 
> allows to set
> > specific handler (any handler with predefined interface) 
> for any parameter
> > parsing event. That allows to implement event driven 
> parameters parsing.
> 
> Would be interesting to see it's interface.

cla::named_parameter<MyFancyStructure>( "fancy_parameters" ) <<
cla::handler( any functor that support appropriate interface ) 
Note that framework does not introduce dependency on boost::function for
example. But do not prohibit to use it as a functor above.
 
> I'd like to backtrack again to command line + Registry use case.
> How can it be supported? Do I have to copy all arguments from 
> command line
> to my own location and do the same with registry? Although my library
> does not handle registry now, adding the support is trivial. 

Ok. You could introduce class like program_options that will provide single
source of program options
Then you could add functions 
operator<<( cla::parser, program_options ) - populate parser based on
program options definitions
operator<<( config::parser, program_options )
...

This way you are not enforce users to use what they are not need to. And
every separate component need not to know about existence of different
configuration means.

> > template<typename KeyPolicy = default_key_policy<> >
> > class key_lookup_policy : public KeyPolicy, public 
> key_based_interface {
> > public:
> [...]
> > };
> > 
> > This class is parameterized with Key policy that 
> encapsulate logic with Key
> > identification, key prefix and key/value separator. This 
> policy allows to
> > set arbitrary string/char as allowed prefix/separator (or 
> even several of
> > them), may successfully skip mismatched tokens and more.
> 
> What I don't like about it is that you seem to mix syntactic 
> and semantic 
> things. The "Key_policy" parameter as you describe it just returns the
> set of option,value pairs. The key_lookup_policy seems to control how
> options are accessed. Why don't separate this two aspects? I mean
> making KeyPolicy a parameter of parser, not of key_lookup_policy

I seem to fail to explain this properly.

Key lookup policy consider input as a series of <key><value> pairs.
Key policy is responsible for how key is look like. Default key policy
presume that key look like this: <prefix><key-name><key/value separator>
Accordingly default key policy is parameterized with PrefixPolicy and
SeparatorPolicy
Default separator/prefix policy is one char separator.
There is also guessing_key_policy that try to guess the parameter name from
key-name provided.
In general cla::parser provide an access to the arguments. Some policy may
provide an "extra" means that's all. For example positional_lookup_policy
provides a way to get a parameter by position.

I hope it will be more clear from sources.
 
> I'm still very much interested in seeing the code. If you plan to
> submit your library as an alternative, it's quite important that
> we two don't say "other's library is bad", but rather summarize all
> the differences, in a form that reviewers can understand.

Sure. But it will always be like: I prefer that - you prefer this.
 
> Personally, I hope that you'll at least agree with validity of
> some concerns I state above.

I am not sure yet.

> 
> - Volodya

Gennadiy.