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

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2003-01-16 13:24:53

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

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

> 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( "=", "?"
)
 
> 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.

> Do you need this really?

Why not? If my parameter  is in a form of question, why not have '?' at the
end?

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

> 
> It looks like cla::argument is provided by the framework.

It is. But it does not mean that all of them are "typed"
 
 
> 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 don't get this. May be it will become more clear from sources.

> > operator<<( config::parser, program_options )
> > ...
> 
> And what those operator<< will do?

Feed option definitions to the cla::parser.

Gennadiy.