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

[Vladimir Prus]

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost