> > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
