[GRASS-dev] g.list -a

Glynn Clements glynn at gclements.plus.com
Mon Jan 8 10:47:01 EST 2007


Martin Landa wrote:

> I can see
> 
> 1) the special flag in g.list (-a -> all types) Q: the 'type'
> parameter should be requested or not requested?

>From an implementation perspective, there is negligible difference
between adding a -a flag or allowing a value of "all" for the type.

The main difference is that a "-a" flag means that you need to remove
the "required" attribute from the option and manually check that
either -a or type= was given.

> 2) the new data type 'all', Q: Should or shouldn't be avoided in other
> manage modules (like g.remove, g.copy)?

It doesn't make sense for the other modules, and might be problematic
to implement; you would either have to perform a separate existence
check for each type or ensure that non-existence of a particular type
is handle correctly (e.g. "g.copy all=foo,foo2" *shouldn't* print a
bunch of warnings: "no region named 'foo'", "no icon named 'foo'",
...).

> Not sure what is better or more useful. If we don't want to use 'all'
> in other modules (e.g. g.copy) I think the flag (1) would be (maybe)
> better.

Even if you used "all" in every module, you would still have to treat
it separately; adding an "all" entry to etc/element_list wouldn't
work. So, I don't really see much difference between:

	if (flag_a->answer)
		...
and:
	if (strcmp(element->answer, "all") == 0)
		...

in g.list.

Actually, I'd favour the latter, as that leaves the
"element->required = YES" intact, which makes the "g.list help" output
a bit more informative. The help output (and HTML/XML output, the
Tcl/Tk GUI etc) automatically indicates if a specific option is
required, while manual either/or checks have to be documented
manually and cannot be enforced by the GUI.

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




More information about the grass-dev mailing list