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

[Vladimir Prus]

Rozental, Gennadiy wrote:

1. You again placed 2 eggs into same basket.
There are 2 levels of configuration file reading
a) level that is responsible for comments lines, empty

lines, continued

lines, include, ifdef, defines and so on
b) level that is responsible for variable definition in

configuration

file

I disagree.

[....]

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

So
to clarify my point let me present an example of my configuration file

----------------------------------------------------------------------------
--------------------------
my_tester.def:

# default value; could be reset in environment
$ifndef tester_home
$define tester_home ..
$endif

my_application::ids "some file name"
my_application::compression "compression definition file name"

tester::debug true
tester::trace_config "trace configuration here"

$include $tester_home/tests_lists

----------------------------------------------------------------------------
--------------------------
tests_list:

test_list::uncompressed::single-message::basic \
test1 \
test2 \
test3

----------------------------------------------------------------------------
--------------------------

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

OK, 3-4 are usefull.

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.

These are 2 layers I was talking about. Note that if my configuration was
not defined in a form <name> <value>, but instead in some other legacy or
XML format, I still could be able to use layer 1. If I need any king of
validation facility (required/optional parameters for example) I could build
it on top of these.

How can you parse XML by defining appropriate continuation character and comment character? You'd need real parser.

I'm not able to comment in detail without seeing the code. However,
whether it's iterator or not is not much import, IMO. The basic usage
I'm envisioning does not require to even explicitly create config_file
instance!

My point is that design should be iterator based. For example, I am actively
using STL algorithms with my config_file_iterator.
Whatever helper wrappers you provide doesn't matter.

Examples would help.

And what the flexibility for? Every config files I've see use the same
format. Everybody know that format. If your code allows to treat "\" as comment character and "#" as continuation character, what advantages does it give. In short: do you have a concrete example where this flexibility is used?

I do. My format is different from yours. But it's not the point. I am sure
that there a lot of legacy formats out there. And if somebody could not use
config_file facility only becouse comment char is $ instead of #, it would
be pity. So again I don't believe such basic facility could afford to be so
restrictive.

I buy your argument about "$", in principle. "In principle", because it should
be really considered how much flexibility is needed by users and acceptable for users who don't need it. Continuation symbol is easy and cheap. $ifdef and
includes --- don't know. XML just can fix into this scheme.

- Volodya

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