[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