Re: [boost] [program_options] Proposed feature to provide option namespace prefixing

Subject: Re: [boost] [program_options] Proposed feature to provide option namespace prefixing
From: Monty Taylor (mordred_at_[hidden])
Date: 2010-06-13 12:05:13

On 06/12/2010 01:20 AM, Vladimir Prus wrote:
> Monty Taylor wrote:
> 
> 
>> Our approach to doing this with Boost.Program_options at the moment is
>> to wrap options_description_easy_init in a class. Something like:
>>
>> class DRIZZLED_API options_context
>> {
>>   const std::string &module_name;
>>   po::options_description_easy_init &po_options;
>>
>>   std::string prepend_name(const char *name);
>>
>> public:
>>
>>   options_context(const std::string &module_name_in,
>>                   po::options_description_easy_init &po_options_in);
>>
>>   options_context& operator()(const char* name,
>>                               const char* description)
>>   {
>>     std::string new_name(module_name);
>>     new_name.push_back('.');
>>     new_name.append(name);
>>     po_options(new_name.c_str(), description);
>>     return *this;
>>   }
>> ...
>> };
>>
>> Then in server plugin registration, a context is created around the real
>> program_options and is is handed to the plugin module:
>>
>>   module.register_options(options_context(module.get_name(),
>> commandline_options.add_options());
>>
>> It seems like a possibly nicer or more integrated approach would be
>> something that would look like this:
>>
>>
>> module.register_options(commandline_options.add_options(module.get_name());
>>
>> And given the mapping of config file sections to name-dotted prefixes,
>> it seems like it wouldn't be a ridiculous addition.
>>
>> Is anybody interested in me reworking what we end up with to be usable
>> or applicable back to the Boost core?
> 
> Hi Monty,
> 
> it seems that what you propose can be accomplished by adding a new
> member to option_description_easy_init, and then doing string
> concatenation in the three operator() methods? It seems pretty reasonable
> thing to do, and I'll be happy to integrate patches to that effect.

Fantastic. I'll work some up for you.

> The only concern is that you simplify definition of options, however, it
> seems that access to options still have to use fully qualified names.
> Or do you have solution for that as well?

I don't have a solution to that, but you're right, I should really come
up with one. I guess my first concern was simply to prevent module
authors from accidentally breaking namespace rules - but their code will
certainly make more internal sense if they can access options using the
same short names.

Will think about it...

Monty