Re: [PATCH 1/4] parse-options: allow git commands to invent new option types

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 29, 2010, 04:03 UTC
Message-ID: <20101129040354.GA30187@burratino>
In-Reply-To: <4CC55C67.8080908@gmail.com>

Stephen Boyd wrote:

> Is there an actual use case where someone needs to completely override
> get_value()? If you move this into the case statement then we get the
> generic error checking of get_value() with the benefits of being able to
> modify the context within a callback.

Yes, I like this idea.

> We could also probably use the
> return value of the low level callback to indicate whether or not to
> take some action after parsing the option. Perhaps something like
> quiting the option parsing loop when encountering such an option?

I'd rather not, since that would involve anticipating needs in advance. This is meant to be a back door for ugly and unusual option types that the mainstream API does not take care of yet. It seems best to allow arbitrary effects.

[...]

>> -#define OPT_SHORT 1
>> -#define OPT_UNSET 2

[...]

Show 12 quoted lines

>> +++ b/parse-options.h
>> @@ -40,8 +41,16 @@ enum parse_opt_option_flags {
>>  	PARSE_OPT_SHELL_EVAL = 256
>>  };
>>  
>> +enum parse_opt_ll_flags {
>> +	OPT_SHORT = 1,
>> +	OPT_UNSET = 2
>> +};
>> +
>
> I hope this isn't necessary.

Because of namespace or something else?

> This reminds me, we can probably simplify that "takes no value" error
> path in get_value() (see below).

Nice.

Thanks, Jonathan