[GRASS5] A naive opinion on how grass *should* work

[Carl Worth]

On May 3, Glynn Clements wrote:
  > Yes; the default region is explicitly chosen by the user. Same for the
 > current region. The only time that the current region is changed is if
 > the user decides to change it.

Except when the suer is just panning/zooming around a map and the
region is being adjusted all the time. ;-)

A d.* command like d.zoom should really not be causing effects similar
to what happens with a g.* command such as g.region.

I think that monitors should keep track of their own
extents/resolution independent of the "current region". If the user
does want to set the current region to that of a monitor, then that
should be through:

	g.region monitor=x0

or some such.

 > > tagged arguments are fine when the arguments are optional.  If the
 > > arguments are required, they may as well be positional.
 > 
 > Tags have a mnemonic value which positions lack. The case where you
 > have one "input" and one "output" parameter isn't sufficiently common
 > to make it a special case. Many commands have either multiple outputs,
 > multiple inputs, or a choice as to the form of the input.

Uhm, doesn't the GRASS option parser already allow for a single
positional parameter? If I recall correctly, the notion is that if a
parameter is missing a tag then is taken to be the value of the first
parameter identified by the programmer.

This is extremely useful for many modules which need only a single
parameter.

It seems to me to that Russell is merely suggesting a generalization
of that technique to allow both positional and tagged parameters when
that makes sense. He also provided a useful criterion for determining
when positional parameter could be used:

	tagged arguments are fine when the arguments are optional.  If the
	arguments are required, they may as well be positional.

And nothing needs to be "special cased" here. Obviously, this is
functionality that can be abstracted and exported by the options
parser.

There's one very simple way to do this that would be a natural
extension of the existing rule and would be immediately useful for
many modules:

	For each argument provided without a tag name, take it as the
	value for each option defined by the module.


One way to end up with fewer required parameters is to, again, adopt
sane defaults. For example:

	r.in.tiff roads.tiff

might as well create a GRASS raster named roads. If you respond that,
"Yes, but all my tiffs have names like TR01CATD that are not only not
useful, but clash across different datasets!", then my response would
be to use:

	r.in.tiff TR01CATD.tiff out=roads

or, even better, combining with my discussion of positional parameters
above:

	r.in.tiff TR01CATD.tiff roads

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth at east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725