[GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
GRASS GIS
trac at osgeo.org
Sat Dec 27 18:56:39 PST 2014
#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:180 glynn]:
> Replying to [comment:178 wenzeslaus]:
>
> > > r63765 generates a warning if GRASS_FULL_OPTION_NAMES is set (to
anything) and the found string isn't an exact match for the given string.
> >
> > Thanks that's good but wouldn't be better to do just the `strcmp`
comparison (to be faster) and fail (with fatal error) which would show
these things in tests (errors are clearly visible, warning must be
searched for in the output). I think the primary use-case for
`GRASS_FULL_OPTION_NAMES` is when you actually want to find the long
options and then it is just more effective to fail. The secondary use-
case, I can think of, is making parsing faster which is only possible if
this check is alternative, not addition. Do you have different opinion?
(This is not necessary to decide before the release I belief because it is
not real API considering the use-cases.)
>
> I just took the simplest route for now. I don't consider performance
issues at this scale to be relevant.
I was hitting some issues when I was calling some modules to do simple
task many time, so I'm looking for ways how to decrease the cost of new
processes but I don't have any benchmark for the option parsing.
> Changing the G_warning() to G_fatal_error() would be trivial, if that's
desired.
Not sure about the others but it makes sense to me to switch to
`G_fatal_error()`.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:181>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list