[GRASS-dev] Re: [GRASS-SVN] r49205 - in grass/trunk: lib/python raster/r.info

[Hamish]

Sören wrote:
> I think r.univar is a good example. Extended
> stats are computed only when specified, because
> of its additional computation effort and memory
> usage. The output is added automatically to shell
> style output in case "-g" is specified.


I much prefer the present way for v.info (in grass7)
and r.univar, where -g gives basic eval-safe info
and -e gives extended parser-friendly output (but
not necessarily eval-safe, ie free-form text fields)
simple, clean, consistent, and doesn't stop others
from working the way they want to work.

wrt unnecessarily viewing this as a 0/1 conflict--
I really don't mind --dump-everything-parse-friendly
flags -- just don't take away the ability to do a
simple 'r.info -r elevation' in the process. These
things (and more generally CLI vs GUI) are not
mutually exclusive, and shouldn't be coded so that
they become so. A little thinking from the other-
guy's end-user workflow goes a long way.

wrt the benefits of keeping language agnostic/safe--
CLI, GUI, perl, python, batch files, shell scripts,
java, R, system(), Ruby, whatever: if we can easily
make the building blocks work for whatever the end
user wants to use, then we should. We shouldn't
impose artificial python-only solutions (and we
should work very hard to make sure that we
haven't), even if nothing in the grass7 codebase
itself uses that language. Users will be most happy
in whatever they are most happy in. If we impose
single solutions we lose their patronage for very
little gain.

wrt r.info's too big pile of flags--
As mentioned in the commit log message for r.info,
-s (res) could be moved into -g (region bounds) as
they are related. Perhaps -t (CELL type) too; it
doesn't have anything to do with the array size
but is a fundamental parameter of the array
definition.

For the purely meta-data items, -u (units), -d
(vertical datum), -p (timestamp), -m (map title)
which are generally not eval-safe could be merged
into a single -e extended-info flag. I don't mind
that at all, what I oppose is making -g eval-unsafe
and forcing debug-dump parsing on CLI users who have
to look at the basic output every few minutes.

if r.info -gre is still too much clutter for you in
the GUI auto-menu it's simple enough to create a
wrapper --script which either hides or consolidates
away the GUI-irrelevant parts.


... I'll reply to specific concerns later (probably
tomorrow); please don't change anything in the mean
time.


regards,
Hamish