RE: [boost] Preliminary submission: command line & config file li brary

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2003-01-17 11:55:08

> > You did not get me. I did not talk about options description at all. As
I
> > keep repeating it another level of abstraction on top of config file,
cla,
> > registry, db whatever. The only purpose of option description is to
store
> > unified description of all named options for the program. it does not
have
> > any parsing functionality inside. Instead when you need to get named
program
> > parameters from some source you feed it with option_descriptions and get
the
> > results from it (option_description may also provide unified way to
access
> > named parameter, that in fact will be a forward to component-specific
access
> > method). option_description design IMO is separate issue and should be
> > discussed separately. Here we talking about config_file component
design. 
> 
> I'm afraid you did not get me as well. You're saying that parsing level
should
> not be coupled with validation level. Yes, there's validation level in 
> config_file class. Yet, it's *rudimentary* validation. I can remove it
without
> much effect on other parts of library. But IMO, that would make the class
less 
> complete. I argue that there's no coupling that worth worrying about.

Again I did not talk about validation. Would I want to add the validation it
be third level on top of two I meant.
level 1. config_file_iterator - see below what it is doing. One more
comment: config_file_iterator produce text lines. Any parser that accept (or
could accommodate ) this kind of input could be used as second level parser.
level 2. parameters parsing - see below what it is doing
level 3. parameters description/validation - holds program parameters and
their value/presence validation functors

> > My config_file iterator is responsible for 
> > 1. comments lines
> > 2. continuation lines
> > 3. ifdef, define, undef, endif ...
> > 4. include 
> > 5. skipping empty lines

> > My parameters handling facility is responsible for parsing, storing and
> > accessing parameters defined in format (configurable) above. It does not
> > know anything about supported parameter by the program it just read what
is
> > in config file. Later you could access parameters by name and get the
value
> > if parameter with the supplied name exists.

> How parsing "test::debug"'s value or "true" differs from parsing 
> "--debug=true" from command line? How accessing "test::debug" by name
> differs from accessing value of "debug" option from command 
> line. *I* think
> that's almost the same. Consequently, I'd rather not have two 
> different 
> classes and two different code handle the same task.

Each component is much more feature reach by itself:
cla provide support for non-named parameters
parameter handling provide support for parameter names with namespaces
If there is something common in simplest cases, reuse could be achieved with
use of some shared parsers. For example parameter handling could use
KeyPolicy classes for parameter identification. But I am not sure it worth
persuading cause may be inconvenient.

Gennadiy