[GRASS-dev] significant change in g.parser behavior for GRASS 7

[Vaclav Petras]

On Wed, Sep 24, 2014 at 7:53 PM, Michael Barton <Michael.Barton at asu.edu>
wrote:

>  I just learned that using upper case characters for a GRASS 7 module
> option means that g.parser will not recognize it. That is for module.
> “r.foo" with options “Abc” and “def”, the command
>
>  r.foo Abc=1 def=2
>
>  will return an error <Abd=1> is not a valid option.
>
>  GRASS 6 does not produce an error in this case. The module will run
> fine.
>
>  This breaks all kinds of existing scripts from GRASS6, as well as
> scripts that are designed to be chained together. I’ve never seen any
> discussion of this. Perhaps I missed it because I was in the field or
> something. Is there a reason for this significant change of g.parser
> behavior?
>
>
I think that the lowercase options are a good choice. There are some
advantages of allowing uppercase like names of some coefficients (you can
have phi but also Phi, k and K) and abbreviation (HTML, PDF). However, I
think that the disadvantages are bigger. According to what I have seen,
with possibility to have both options (upper and lower case), people would
create options slope, but some other Slope, some perhaps even SLOPE. With
two words in the option name, it would be even worse: elevation_model,
ElevationModel, Elevation_model, Elevation_Model, ...

The consistency is not the only reason, we have there also Python and Bash
scripts. In Python, the option names are function parameters which in the
most Python coding styles should be lowercase (with or without underscores)
which is exactly what GRASS 7 parser wants. For Bash the situation is
different, we uppercase all the options (I believe in both 6 and 7) because
they are part of variable names, so of course we can do this only if we
know that all the letters have the same case, in 7 we know, they are
lowercase.

I don't think that occasional need for uppercase letters outweighs the
potential issues which would be potentially encountered by everyone.

Unfortunately, I'm not sure where is this documented and what was the
reason when it was introduced, from the logs it seems that the behavior was
introduced 6 year ago by Glynn:

http://trac.osgeo.org/grass/changeset/32261

I don't see any other place where the relevant check is done, so I think it
is this change. The check should be actually done when creating an option,
not when the option has a value (now it look like as an user error rather
then programmer's error).

Glynn, can you please comment on it?

Vaclav


 Michael
>            ____________________
>  C. Michael Barton
>  Director, Center for Social Dynamics & Complexity
>  Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
>  Arizona State University
>
>  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>  www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140924/60be323e/attachment-0001.html>