[GRASS-dev] g.list -a
Martin Landa
landa.martin at gmail.com
Tue Jan 9 03:10:13 EST 2007
Hi,
2007/1/8, Glynn Clements <glynn at gclements.plus.com>:
> > 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.
OK, your argumentation seems to be right.
1) Q: allowing multiple data type would be useful for the user - is it desired ?
e.g. type=rast,vect,region
2) It seems better to add the type 'all' to g.list manually
(especially because of the requested type parameter). I am not sure
how to do it in an elegant way (see the patch) - my approach seems to
be very ugly.
Any objections or suggestions?
Martin
--
Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: g_list_all-4.diff.gz
Type: application/x-gzip
Size: 2926 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070109/26b8acb0/g_list_all-4.diff.gz
More information about the grass-dev
mailing list