[GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
 Reporter:  martinl               |       Owner:  grass-dev@…              
     Type:  task                  |      Status:  new                      
 Priority:  blocker               |   Milestone:  7.0.0                    
Component:  Default               |     Version:  unspecified              
 Keywords:  standardized options  |    Platform:  Unspecified              
      Cpu:  Unspecified           |  
----------------------------------+-----------------------------------------

Comment(by wenzeslaus):

 Replying to [comment:117 mlennert]:
 > Replying to [comment:116 wenzeslaus]:
 > > Replying to [comment:115 neteler]:
 > > > I see the problem of no consensus here. Do we need to fork GRASS at
 this point or postpone the release forever? (irony flag on or off as you
 wish)
 > >
 > > My understanding was that we have or we are very close to consensus. I
 the last round, [comment:108 martinl] suggested "`raster` and (`raster_3d`
 or `raster3d`)" for options and elements (when leaving module names as
 they are). [comment:112 mlennert] agrees with not renaming module names
 (if I understand correctly).
 > >
 > > [comment:111 annakrat] and [comment:113 hcho] don't want the
 underscore for 3D raster, so this changes "`raster` and (`raster_3d` and
 `raster3d`)" just to "`raster` and `raster3d`". [comment:102 I] already
 said that I prefer `raster3d` over `raster_3d`. In my opinion such a
 common option name as one for 3D raster (common for me and name of one of
 the basic types) should not have an underscore. But [comment:114 glynn]
 does not see the point in not using underscore in case of `raster_3d`. So,
 this is the only unclear part depending on how strong is Glynn's opinion.
 >
 > Why only Glynn's ? For me that question goes both ways. I have to admit
 that I don't understand the opposition to raster_3d.

 So, sorry for misquoting you.

 > Is this only based on aesthetics ? In terms of ease of programming and
 usability, I have the feeling that raster_3d is superior as it allows you
 to use the current parser behaviour to use abbreviations like r3 which
 raster3d doesn't.

 As I said before, I don't care much about abbreviations. I even consider
 them bad. They are bad for the source code and most of the scripting
 because of readability (I think we have a consensus on that). And they are
 bad for manuals and tutorials because they are harder for user to
 translate to GUI or QGIS (GUI or processing). So then I don't see the
 point in putting so much effort into the abbreviated options. And I also
 think that we cannot unabbreviate everything, some options would be just
 too long, too unpractical. Anyway, I can manage to write `raster_3d`
 everywhere and I will hope that everybody will do the same for all GRASS
 core code and addons. Perhaps it would be useful to have some
 environmental variable to disable abbreviating which could be used for
 testing (or to speed up the parsing).

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:118>
GRASS GIS <http://grass.osgeo.org>