<p dir="ltr">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?</p>
<p dir="ltr">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.</p>

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