"Vladimir Prus" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Gennadiy,
>
> > About month ago, while working on Boost.Test issues I was faced with the
> > need for the more or less full featured command line argument parser. I
> > recall that you were working on one and took a look on some of your
> > preliminary code in vault area.
>
> What code, specifically? The only think I remember placed there is
> a low-level command line parser, which was never meant to be the
> single solution. In fact, it is now meant only for
>
> 1. "I don't want to depend on Boost" use cases
> 2. Possibly, for adding some very custom hooks.
>
> > And ... was really disappointed. I do not
> > believe that any "solid" design could fit for variety of different
> > needs/expectations that exist. One big class with many many
options/styles
> > does not look like good design decision. I was not able to look into
deep
> > details with your current submission, but from what I view even if it
better
> > it still has similar design. While we are at it I could make 2 remarks
about
> > 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.
>
> > b) see separate post regarding you config file design
> > with is also unsatisfactory IMO.
>
> I have not seen any separate post. Are you sure you've sent it?
It was too late yestaday for another post. I would not be able to comment
now also. See soon.
>
> > So I made my move and implemented my own solution, that I will be
call:
> > CLA framework. It's still missing some bits and pieces, particularly
docs is
> > not started yet. But I will present it as an alternative to your
submission.
> > (Though I may not be able to work on this within following month due to
> > extreme load with other activities). Here is short description of my
design.
>
> Is it possible to take a look at the code, too?
Ok. I will try to clean up and present some compilable snapshot
> > 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.
> 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.
> [...]
> > 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?
> > 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.
> > 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>
Sorry - need to go.
To be continued.
Gennadiy.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
