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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-17 01:45:34

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