[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] [RFC] New options handling
From: |
Timothy Brownawell |
Subject: |
[Monotone-devel] [RFC] New options handling |
Date: |
Sun, 22 Oct 2006 18:28:16 -0500 |
Thoughts, comments? Does this sound like a good way to handle things?
New option handling
===================
net.venge.monotone.experiment.options is a rewrite of our options
handling. It gets rid of boost::program_options, and moves option
variables out of app_state and into an 'options' class.
It does not yet have any new unit tests for option handling.
option.cc has tokenize_for_command_line() and wordwrap() functions
that could possibly be moved to simplestring_xform.{cc,hh} .
Class overview
--------------
concrete_option
This is a single option; you probably won't use it directly.
it has a long name, a short name, a description, and
'setter' and 'resetter' functors.
concrete_option_set
A collection of options. It has a 'reset' function that
calls each option's resetter functor, and a from_command_line
function that will call the 'setter' functor that belongs to
each given option.
option<T>
Like concrete_option, except that instead of functors it has
member-function-of-T pointers. It also has an 'instantiate'
function that takes a T* and converts it to a concrete_option.
option_set<T>
A set of option<T>, with an 'instantiate' function that
will instantiate each option<T> in it and return them as a
concrete_option_set.
options.{cc,hh} and options_list.hh
These define an "options" class, and several option_set<options>
static objects that represent individual options and sets of
options (all global options belong to the same set, and there is
a set for diff-related options).
Usage
-----
concrete_option_set and option_set<T> each have an operator| that
returns the union of two sets, or the addition of an option to a set.
They also each have an operator() that takes the same arguments as the
appropriate concrete_option or option<T> constructor, and appends a new
option to the set.
concrete_option_set has a get_usage_str() function that returns a usage
string, word-wrapped to the terminal width, for all options it contains.
It also has a reset() function that will reset all the options it
contains. It has a pair of from_command_line() functions that will parse
a command line and store the results into the options in the set.
Special option names:
--xargs/-@ takes one argument which is the name of a file to
parse and insert into the list of tokens.
-- is the name of the positional option. If positional options
are to be accepted, the option set must include an option with
this name. If a '--' is seen in the input all further items are
treated as positional options, even if the start with - or -- .
An option with empty names is never set. These can still be
useful if there is a group of options that all operate on the
same variable; put them in a option_set along with a nameless
option that has its reset function set up to reset that
variable. This is used by the options* files.
Exceptions:
from_command_line() will generate these, which are all derived
from option::option_error :
option::unknown_option
from_command_line() encountered a given option that
doesn't match the name of any options it knows about.
option::missing_arg
An option that takes an argument was given without one.
option::extra_arg
An option that doesn't take an argument was given one.
option::bad_arg
The setter function failed (see below).
from_command_line() will catch these if a setter function
throws them:
option::bad_arg_internal
The given argument is invalid. When throwing this, give
it a reason that the argument is invalid.
boost::bad_lexical_cast
options_list.hh
---------------
This uses several macros to define options.
OPTSET(name)
Defines a named group of options.
OPTVAR(optset, type, name, default)
Defines a variable that belongs to a given set of options.
When that group is reset, the variable will be reset.
OPTION(optset, name, has_arg, option, description)
Defines an option. The name is in the same namespace as the
optset names; these names are what is given to the CMD macro.
'option' is a string like "long,s", which will match when
--long or -s is given on the command line. 'has_arg' is a
boolean that says whether this option expects an argument.
OPT(...), GOPT(...)
Convenience macros defined at the top of options_list.hh, for
either command-specific or global options that want a variable
of the same name as the option.
Currently, the setter function for each option is also in this file.
These really should be split into a separate file so that changing one
doesn't mean recompiling the world.
--
Timothy
Free (experimental) public monotone hosting: http://mtn-host.prjek.net
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Monotone-devel] [RFC] New options handling,
Timothy Brownawell <=