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

Subject: [boost] [program_options] Proposed feature to provide option namespace prefixing
From: Monty Taylor (mordred_at_[hidden])
Date: 2010-06-11 19:49:42

Hi!

I'm a developer on the Drizzle project, and we're currently replacing
the home-grown getopt wrapper we inherited from the MySQL codebase with
Boost.Program_options. So far, we're thrilled and it's going great, so
thanks!

We've focused on the client utilities to start, but as we're coming up
on the server, we have an issue that we have an internal solution for,
but which seems like it might be something that could be more generally
useful, so I thought I'd mention it here, and if there is any interest,
I can work up a proper code submission.

The situation has to do with plugin modules and option names. In our
current system, we enforce an option name prefix that matches the module
name. For instance, if you are the InnoDB plugin author, you would
declare an option named "buffer_pool_size" which would be presented to
the user as "--innodb_buffer_pool_size", and the server/plugin
registration handles prepending the module name to the option name for
you. (you cannot choose to not do this)

For those following along at home, you'll notice the _ we're using for
the concatenation - we're happy changing that to be a "." so that the
program_options config file sections will work in a sensible way.

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?

Thanks!
Monty