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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-15 10:43:20

Gennadiy Rozental wrote:

>>>your submission: a) None of 5 compiler configurations installed on my XP
>>>could not compile it.
>>
>>:-(
>>I've made some corrections recently. Did anything improve?
> 
> I've tried version you announced yesteday.

Hmm... can you provide error messages?

>>Is it possible to take a look at the code, too?
> 
> 
> Ok. I will try to clean up and present some compilable snapshot

OK.

> 
> 
>>>   Class cla::parser is core class in a framework. It's definition looks
>>>like this:
>>>template<typename LookupPolicy>
>>>class parser : public LookupPolicy {
> 
> ...
> 
>>OK, disagreement begins. I thought that someone could suggest using
> 
> policies.
> 
>>But considering it, I came to conlustion that they don't give anything.
>>Program options are just (name, value) pairs. If you add a mechanism to
>>store them into program variables, you have everything.
> 
> 
> There are many diffirent algorithms how you could parse program option
> values from input. Name part is optional. Consider positional arguments. Or
> I have one policy that I forgot to mention: chain_lookup_policy. It's work
> is based on Chain of responcibilities Design pattern. In this case Every
> parameter knows how to parse itelf out of input. And this identification may
> not be the name at all.

I would say that it's a big question how much flexibility is needed. My 
position is that the command line should not go beyond existing styles.
Can you suggest some style which require chain_lookup_policy and still
legible for users?

>>Further, assume this situation. My program would like to handle options
> 
> that
> 
>>can be specified at
>>1. Command line
>>2. Config file (ini)
>>3. An XML config file
>>4. Windows registry
>>
>>Things like validation, and default values really apply to all of them.
>>I'd like to declare all options once, and then get them from those
> 
> sources.
> 
>>In your design, I'd have to declare 4 different parsers, feed them all
> 
> with
> 
>>options, and the parse all the sources, right?
> 
> 
> IMO tis is majoy drowback of your solution - you put too many eggs into the
> same busket. Compare number of peeople that need only CLA framework with
> number of paople that need  all you mention above. Or even CLA and config
> file. Numbers are incomparable. What I would od is to present independent
> solution. Plus  some kind of unified interface that works on different level
> and allows ot compine different configuration means.

I don't know how to compare number of people who need command line to the 
number of people who *also* need config file. I suppose that as your program
grows bigger, you're likely to need config file too. The transition should
be simple.

What would be your "unified interface"? You'd still need to declare where 
options value should be required or not, how to validate it, etc. Do you
suggest to create some class and use the same manipulators to initialize it?
Then the command line parser should not know about those manipulators.. it
should take the "option description" class.

>>>Lookup policy
>>>   Lookup policy is in a sense an algorithm for parsing the arguments
> 
> from
> 
>>>the input provided.
>>
>>If it's the parsing algorithm, then why it's called "lookup policy"?
> 
> 
> This algorithm defines how we perform lookup of the parameter in the input.
> Do you have better name?

"parameter extraction policy" or "parameter search policy" sound better.

>>>Each specific lookup policy could incur what type of the
>>>parameters/modifiers it's supports. Currently framework itself present
>>>following lookup policies;
>>>
>>>key_lookup_policy          - each parameter is identified by unique key
>>>positional_lookup policy  - each parameter is identified by position in
>>>input
>>>dual_lookup_policy         - each parameter is identified by dual (most
>>>probably long/short) key
>>>getopt_lookup_policy      - getopt style option parsing (with sticky
>>>options)
>>
>> From your description it looks like some of policies deal with parsing
>>and some with parameter naming. Or are they responsible for both?
> 
> 
> Policy only defines how we perform *lookups* - parameter identfication.
> There is separate class (I did not mention) - interpreter - that is
> responcible for parsing the parameter value from input after the parameter
> was identified. But it's optional - you are not required to used namely this
> mena to parse the value.

Oh.. it's even more complicated! Are your command line syntaxes that complicated?

>>>simple_xml_lookup_policy - as a prove of concept lookup policy that
> 
> allows
> 
>>>to parse parameters passed in XML format
>>
>>I don't understand this one. Can you explain?
> 
> 
> my_program <debug>true</debug> <delay><seconds>2</seconds></delay>

Do you really think that there is *one* user who would be happy with
this command line style?

> 
> Sorry - need to go.
> 
> To be continued.

Looking forward.

- Volodya