From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mon, 29 Nov 2010 04:03:54 GMT
Subject: Re: [PATCH 1/4] parse-options: allow git commands to invent new option types
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
[...]
>> +++ 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