[m-rev.] for review: changes to option handling
zoltan.somogyi at runbox.com
Fri Sep 18 01:19:22 AEST 2020
2020-09-17 18:03 GMT+10:00 "Peter Wang" <novalazy at gmail.com>:
>> + % process_options_cookie(OptionOps, Args, OptionArgs, NonOptionArgs,
>> + % OptionTable0, Result, OptionsSet, !Cookie, !IO):
>> + %
>> + % This predicate is similar to process_options_track, but it also
>> + % threads a piece of state of a user-specified "cookie" type through
>> + % all the handlers of special options, so that each special handler
>> + % can read from and/or write to this state. Amongst other things,
>> + % this can be used by the caller to recover the *sequence* in which
>> + % special options are specified, information that is not present
>> + % in the (orderless) set of specified options.
>> + %
>> + % XXX Should we return the final value of CookieType
>> + % if the value we return for Result is error(...)?
> I say yes.
In that case, if there is an error, should the new predicates return
the option table as well, as it was just before the error? We can't make
that change for the existing predicates without breaking existing code,
but that is not an issue for the new predicates.
> I assume the rest of the changes are trivial so didn't look deeply.
Yes, they are simple.
I will follow your other suggestions.
More information about the reviews