[boost] Re: Preliminary submission: command line & config filelibrary

[Vladimir Prus]

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


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