#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> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev