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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-17 02:49:50

Rozental, Gennadiy wrote:
>>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.
> 
> 
> What if changing to custom ownership policy will bring you 10% speedup in
> effciency important part of the code? Would you still say - "never, I only
> use one smart pointer in a program"?

I'm likely to eliminate shared pointers in that part altogether. Further,
what if in 6 month the code is not longer performance bottleneck, but
different smart pointer is still there?

>>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.
> 
> 
> I don't say that you solution is unable to do anything. But I still prefer
> more flexible one. For example what if my parameter has 2 descriptions, one
> long - for long help message and one short for usage message. Where does it
> fit in your interface?

That's a good question. Really.

I'd derive a new class from option_description and add the required member
functions.

There are some problems now, which should be fixed before this recipe can
we working --- some interfaces have to suffer minor change. But surely, no
complete rewrite is needed.

>  
> 
>>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.
> 
> I do not completely understand yuor "module" principles. So could not
> comment on this. But As I mention, in my terms one could define several
> parsers that does not need to know about each other and process cla in
> chain.

This has some drawbacks:
1. Each module has to be given "data sources". If that's argv,argc. It's 
probably OK. What if it's registry?
2. Each module has to depend on parsing library, including parsers.

>>Did you look at "option_description" interface. The 
>>constructors have at most three parameters. 
>>I positively can't envision any confusion. 
> 
> 
> Add second description, optional/requires, mulitplicable (those are some of
> the "features" supported by my parameters) and you could easily see one.

Why should I add those as constructor arguments?! Here's an example from the docs:

     desc3.add_options()
             ("output,o", "file", "where to send output")
             ("magic", "value", "magic value for the program")
                 .default_value("43")
             ;

You see, "default_value" is quite explicitly named.

>>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.
> 
> 
> Possibly much more in my case:
> 
> cla::named_parameter<int>( foo ) << cla::optional
>                                                  << cla::default_value( 1 )
>                                                  << cla::place_to( foo_value
> )
>                                                  << cla::description( "my
> lovely foo argument" )
>                                                  << cla::format_descr(
> "integer value" )
>                                                  << cla::prefix( "/" )
>                                                  << cla::separator( "=", "?"
> )

As my example above shows, you can use simple syntax for two arguments and 
explicit/named for all others. Take a look at Boost.Graph: it uses named 
arguments, but mostly for numerous details such as "color_map". You don't have 
to write

    transitive_closure(graph_param(g));

>>I might be wrong, but using "?" to mean optional construct is 
>>almost universal
>>convention. I can hardly imagine it's non-obvious.
> 
> 
> Maybe for unix users. You assumption is not obvose in general case.

Bikeshed. The question is up for others.

>>Do you need this really?
> 
> 
> Why not? If my parameter  is in a form of question, why not have '?' at the
> end?

Uph.. I'm sorry, I completely misunderstood your question. If you want

    my_program --roll_trace_file? "yes"

you can have it, without any efforts from my part:

    options_description desc;
    desc.add_options()
    ("roll_trace_file?", "arg?", "roll trace file)
    ;

"rool_trace_file?" names the option, or in your terms, parameter.
"arg?" specifies that there's an optional value, called "arg?". The
name of value will be used only in help message.

>>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)
> 
> 
> May be that's because they stick to one-char parameters identification
> instead of more expressive solution?

I think that if you have "--revision" which can occur two times for one
command, one time for another, and has special value syntax for the third,
it's still confusing. The command line syntax is just too complicated.

>>>operator<<( config::parser, program_options )
>>>...
>>
>>And what those operator<< will do?
> 
> 
> Feed option definitions to the cla::parser.

Eeh.. that's only possible if program_options, config::parser, and cla::parser
have the same interface for declaring options. If you add custom modifier to
cla::parser, you have to add it to program_options, and the to config::parser
and then to registry::parser, if you have it.

- Volodya