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