[GRASS-dev] RFC: Module Option Parser

[Glynn Clements]

Brad Douglas wrote:

> > > In order to make this work and keep the many options from spamming
> > > i.ortho.photo --help (as many of the above selections have multiple
> > > options that are not related to each other), I would like to propose the
> > > following changes:
> > > 
> > > - Create a new function: G_define_selection ();
> > > - Add another option to G_define_option () that would link an option to
> > > a selection:
> > >     dem_opt = G_define_option ();
> > >     dem_opt->key           = "dem";
> > >     dem_opt->type          = TYPE_STRING;
> > >     dem_opt->required      = NO;
> > >     dem_opt->multiple      = NO;
> > >     dem_opt->description   = _("Digital Elevation Model");
> > > --> dem_opt->selection     = "dem";   <--- new option
> > > 
> > > So...when I do 'i.ortho.photo --help', I get a list of selections to
> > > choose from.  When I do, 'i.ortho.photo select=dem --help', I only get a
> > > list of options associated with the "dem" selection (ie. dem_opt).
> > > 
> > > Comments, suggestions, and better ideas are always welcome.
> > 
> > Extending the infrastructure for a single module is normally a clue
> > that the problem is with the module.
> 
> I may have had i.ortho.photo in mind, but I intentionally tried to make
> it extensible to other modules.
> 
> Modules that could readily benefit (by no means a complete list):
> v.distance
> v.lidar*
> v.lrs*
> v.net*
> r.resamp*
> v.surf*
> r.li*
> r.le*
> r.support*
> 
> > If most of the options only apply to a specific "mode", that suggests
> > that each mode should be implemented as a separate module. If they
> > share common code, make it a library.
> 
> I disagree.  Currently there are about 150 raster and 65 vector modules.
> The list is not shrinking and becoming a bit unwieldy.

I don't see a problem with having a large number of modules.

>From a developer's perspective, many small modules are easier to deal
with than one large module, as you have to analyse less code to
understand the consequences of making any given change.

I view modules as being "functions" within an API, rather than as
applications within a package or suite.

Having distinct "modes" within a single module should only be used
when the difference in code is small and most options apply to most
modes.

If the amount of code in common and the amount of code specific to
each mode are both substantial, I would prefer multiple modules with
the common code in a (private) library.

A good example of something which shouldn't be a single module is
r.support. Modifying the category list and modifying the colour table
have almost nothing in common.

Similarly, the various r.resamp* modules all use fundamentally
different algorithms and have different parameters (r.resamp.rst has
many parameters, most of which aren't applicable to other algorithms). 
A combined resampling module would be nothing more than a front-end to
what are essentially several entirely different modules.

-- 
Glynn Clements <glynn at gclements.plus.com>