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);
>> 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);
>> 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:
>> It seems like a possibly nicer or more integrated approach would be
>> something that would look like this:
>> 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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk