[GRASS-dev] [GRASS-SVN] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raster/r.neighbors raster/r.out.bin raster/r.quant raster/r.resamp.filter raster/r.series raster/r.series.accumulate raster/r.series.interp raster/r.stats.quantile vector/v.colors vector/v.external.out

[Huidae Cho]

My implementation of the "exclusive" member, which you reverted, can handle
all these cases, I think. But since you reverted it, I think you didn't
agree with my interface or implementation?

IMO, passing option/flag names to G_option_required() has its own
disadvantage because changing option/flag names takes more effort. If you
have valid reasoning behind adding functions rather than adding a member,
just like I did, I would prefer to pass *Option and *Flag pointers to those
functions. But I guess it can be a little tricky to pass two different
types of pointers.
On Jun 6, 2014 2:42 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

>
> Huidae Cho wrote:
>
> > I was thinking about the same thing. Maybe add char *exclusive_group to
> > Option and Flag and G_parser() takes care of exclusiveness?
>
> There are two relatively straightforward cases for option
> interdependencies:
>
> 1. At most one option from a set may be provided (mutual exclusivity).
>
> 2. At least one option from a set must be provided (more general form
> of the ->required field).
>
> Both of these requirements may apply, i.e. exactly one option from a
> set must be provided.
>
> But there may still be cases where that isn't sufficient, and you'd
> need generalised boolean expressions. E.g. Where you need either A or
> both of B and C. Or if you use A then B is required, otherwise it's
> invalid.
>
> It would be a fairly simple matter to add a function to evaluate a
> boolean expression supplied by the module. But that wouldn't be much
> help either to the GUI (which ideally would use the interdependency
> information to e.g. grey out invalid options) or for generating error
> messages (we want something more informative than "that combination of
> options isn't valid").
>
> So, in the first instance I'd suggest adding:
>
>         // at most one option from a set
>         void G_option_exclusive(const char *opt, ...);
>
>         // at least one option from a set
>         void G_option_required(const char *opt, ...);
>
>         // if the first option is present, at least one of the other
>         //  options must also be present
>         void G_option_requires(const char *opt, ...);
>
> All functions take a NULL-terminated list of option/flag names
> (leading "-" indicates a flag).
>
> The argument-checking code would be migrated to the new functions. Any
> cases which still cannot be expressed would be reported to the list
> for further consideration.
>
> Once we've either covered all of the cases or concluding that any
> remaining cases cannot reasonably be incorporated into any general
> framework, we can work on exporting this information via
> --interface-description etc.
>
> --
> Glynn Clements <glynn at gclements.plus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140608/3781e19e/attachment.html>