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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-16 06:06:03

Rozental, Gennadiy wrote:
>>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.

Yea.. there's "fixed rigid interface" --- but *only* for the most common
things. You can't avoid declaring name and parameter presense, and that's
all *required* by interface. Things like default value, validator, 
notification function, etc, can be provided separately, if there's the need.

> On the other hand with my interface end-user( programmer) could introduce
> his own parameters and modifiers types within bounds if existent framework.

I'd like to draw an analogy with shared_ptr. You can provide smart pointer 
with 5 policy parameters, that user can redefine. Still, I would use
boost::shared_ptr, just because I don't want 10 incompatible smart pointers in 
my program due to small advantage each one has in special situation.

Likewise, if you have a single interface for declaring options, you should
settle of a fixed set of properties. I believe that your "handler" and my
"validator" and "notify" mechanisms can be used to cover situation where that
set of properties is not sufficient.

If you don't have such single interface, you'll reduce chances for reuse.
If a module adds options to global parser using some non-standard features,
you'd have to carry that global parser together with the module.

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

Did you look at "option_description" interface. The constructors have at most 
three parameters. I positively can't envision any confusion. You suggest, 
instead of easy syntax for name/parameter and explicit syntax for everything 
else, to use explicit syntax for everything.

In Python, you can use named arguments to function. What you propose looks
like using named arguments for calling function with two or three parameters.

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

I might be wrong, but using "?" to mean optional construct is almost universal
convention. I can hardly imagine it's non-obvious.

> And what is the type of it? 

The type of argument *can* be specified. Did you look at the example I've 
linked? It just was not appropriate to this example.

> IMO
> much better more expressive:
> 
> named_argument<int>( arg ) << cla::optional
> 
> BTW what if I want ? as a part of my parameter name?

Do you need this really?

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

I think that *existing* habits shold be supported. However, the library should
encourage some "standard" command line style. Contrived command line style is
only an inconvenience to user. As an example: what does "-r" option to CVS 
does? (It has 2 unrelated meanings, and about 4 syntax variations)

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

OK, this solution appears viable. OTOH, I'm not sure this scales well to more 
option sources.

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

It looks like cla::argument is provided 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.

You'd still need to function-like logic inside your code, I think. You should
call object of some concrete type, and "any functor" must be converted to
that type. Is that duplication reasonable?

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

And what those operator<< will do?

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

Hope to see them.

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

Not necessary. More constructive approach is "I want to do that-and-that. 
How?" Another usefull question is how many complexity something adds and
how many users would care about added functionality.

- Volodya