#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:82 glynn]: > Replying to [comment:80 wenzeslaus]: > > I'm for explicit long descriptive option names but if it creates more issues then it solves (`3draster`) and if everybody would be using the shortened version all the time anyway (`rast`, ...), I prefer not to change them. > > Code should always use the full name. Abbreviations are intended for interactive use. This is what I mean. If we want better interactive use, let's improve it but not at expense of writing the code. (`3draster` is improvement for interactive use but it makes code worse by requiring `_3draster`.) As I said before, short options are mostly advantageous for unix-like command lines, so let's use what it used there, the Tab key auto-complete. This is definitively not an obsolete thing, for example Git is using it extensively, SVN supports it too. Another solution for abbreviating `raster` and `raster3d` which solves the problem at the level of abbreviating and does not make the code worse (although it might harm a little bit) is changing the ambiguity rules as [comment:75 Glynn suggested in comment 75]. My first impression from shortening actually was that it counts matching letters for each option and gives a best match. But this is not (unlike Tab key auto-complete) completely isolated from calling the modules from some code, so I'm afraid of two things. First, that it can become dangerous for people not using the long options in the code (e.g. for compatibility reasons). Second, that the option matching can become so costly that it would actually make module calls more expensive. -- Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:84> GRASS GIS <http://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev