[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 glynn):

 Replying to [comment:137 hcho]:

 > > No, not the last word of the option name. You cannot skip any words
 separated by an underscore. rm= is not ambiguous in this case because the
 shortest option name that matches rm= is raster_map=. If one wants
 raster_map2=, use rmap2=, not rm2= (no abbreviation inside a word).
 >
 > I mean the shortest option name with no more following underscores. 'r'
 for raster, 'm' for map, and no more underscores after 'raster_map'.

 This still has a couple of problems:

 1. match_option() now needs to return the "strength" of a match, and the
 code which calls it (two places: once for option names, once for
 opt->options values) needs to consider this when determining whether a
 match is ambiguous.

 2. match_option() now has to try to find a stronger match if there is one.
 E.g given an option named "ab_b" and an argument "ab", the "b" can match
 the second letter of the first word or the first letter of the second
 word. Currently, it will find the first case and return. The change would
 require that it finds the first, but keeps searching for a stronger match
 in case an ambiguity subsequently needs to be resolved.

 The "prefix" rule suggested in [comment:101] also requires complicating
 the calling code, although it doesn't require changes to match_option()
 itself. Specifically, it needs to record all of the options which matched;
 it can't be reduced to "finite" state.

 But keeping track of which options matched would allow us to provide a
 more informative error message in the event that the given name is
 ambiguous (i.e. the error message could list all of the matches).

 The "strength" approach is perhaps a bit simpler to implement for the
 caller, in that it doesn't need to track which options matched, only the
 count and strength. If an option provides a strong match, and all prior
 matches are weak, it sets the match counter to one (discarding any number
 of weak matches). Once at least one strong match has been found, any weak
 matches will be ignored. At the end, a match is unambiguous if the count
 is one (i.e. one weak match and no strong matches, or one strong match and
 any number of weak matches).

 OTOH, it's also a bit less convenient, as the user has to provide some
 part of each word, even when this doesn't reduce the set of candidates.
 It's also possibly less clear to the user exactly what they should type to
 avoid the ambiguity.

 To be honest, the last point is my objection. I'd be less concerned about
 the increased complexity of match_option() if the result was an
 unambiguously better user experience (although I am slightly concerned
 about the possibility that match_option_1() might go from having
 exponential complexity in theory to actually having exponential complexity
 in practice).

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