Re: partial option parsing

Jack Moffitt wrote:
> Now the problem is that I want to factor out certain commands to a
> common place, since there are common options to subcommands that most
> subcommands will use.

Sounds like a job for classes and subclassing.  The superclass could
populate the common options, and subclasses could populate their specific
options.

> I think this will work as I want.  Do you see anything wrong or have any
> further suggestions?

Looks fine, at least to begin with.  Don't be afraid to throw away a
subsystem design when the application outgrows it.

There are all sorts of ways to deal with dynamic options.  In Docutils, we
have a multitude of components, each with their own options.  A front-end
tool puts components together, and an "option_spec" structure is read off
each one to form the final command-line tool.  This is combined with config
file processing to form a complete runtime settings system which works quite
well, and feels natural.

-- 
David Goodger  <[email protected]>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/



-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en