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

Subject: Re: [boost] [program_options] Proposed feature to provide option namespace prefixing
From: Chard (boost_at_[hidden])
Date: 2010-06-14 06:36:59

Monty Taylor <mordred <at> inaugust.com> writes:

> 
> On 06/12/2010 01:20 AM, Vladimir Prus wrote:
> > Monty Taylor wrote:
> > 
> >> 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
());
> >>
> >> Is anybody interested in me reworking what we end up with to be usable
> >> or applicable back to the Boost core?

This sounds similar to something we're doing, where the first argument on the 
command-line decides the mode of the program.

We wanted the convenience of being able to use a single configuration file, 
but also the convenience of not having "section." prefixes on the command-
line.  E.g.

#####
#/config.ini
 
[mode_1]
opt1=...
opt2=...
optFoo=...
 
[mode_2]
opt1=...
opt2=...
optBar=...
####

theProgram mode_1 config.ini
theProgram mode_1 opt1=value
theProgram mode_1 config.ini opt2=override
theProgram mode_2 optFoo=value  // error: option not available for mode_2

At the moment we have a (simple, but a bit hacky) solution of prepending the 
mode onto the command arguments, so +1 for anything that moves code out of our 
base into the library ;-)

> > 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.

Is this a case of being able to 'bind' the variables_map to a domain, too?