Microproject idea: new OPT_* macros for PARSE_OPT_NONEG

Microproject idea: new OPT_* macros for PARSE_OPT_NONEG

[Duy Nguyen]

Currently in order to avoid --[no]-xxx form we have to resort to
declare full struct option. It'd be nice to have a set of OPT_* macros
with PARSE_OPT_NONEG set. Find and update all "struct option []"
declarations with the new macros (including ones that should never
accept --no- form, but do anyway).
-- 
Duy

Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG

[Michael Haggerty]

On 03/07/2014 02:38 AM, Duy Nguyen wrote:
> Currently in order to avoid --[no]-xxx form we have to resort to
> declare full struct option. It'd be nice to have a set of OPT_* macros
> with PARSE_OPT_NONEG set. Find and update all "struct option []"
> declarations with the new macros (including ones that should never
> accept --no- form, but do anyway).

I added this to the list, with the following warning:

    This is more a milliproject than a microproject

because to me it feels considerably more involved than the other
microprojects.  To  complete it, the student will have to understand at
least part of the parse_options() API, which is more than a 15 minute
job by itself.

Thanks,
Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG

[Duy Nguyen]

On Fri, Mar 7, 2014 at 2:39 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 03/07/2014 02:38 AM, Duy Nguyen wrote:
>> Currently in order to avoid --[no]-xxx form we have to resort to
>> declare full struct option. It'd be nice to have a set of OPT_* macros
>> with PARSE_OPT_NONEG set. Find and update all "struct option []"
>> declarations with the new macros (including ones that should never
>> accept --no- form, but do anyway).
>
> I added this to the list, with the following warning:
>
>     This is more a milliproject than a microproject
>
> because to me it feels considerably more involved than the other
> microprojects.  To  complete it, the student will have to understand at
> least part of the parse_options() API, which is more than a 15 minute
> job by itself.

I don't know the scope of these microprojects, but yes I think it'll
take a few hours for this. By the way, a bit more thought on the idea:
instead of making OPT_BOOL_NONEG() that sets NONEG, we could make
OPT_BOOL_FLAGS(..., NONEG), which is more flexible.
-- 
Duy

Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> I don't know the scope of these microprojects, but yes I think it'll
> take a few hours for this. By the way, a bit more thought on the idea:
> instead of making OPT_BOOL_NONEG() that sets NONEG, we could make
> OPT_BOOL_FLAGS(..., NONEG), which is more flexible.

What does a boolean that can never be set to false achieve, by the
way?  If you have

    [alias]
        foo = bar --frotz

then you may want to be able to say "git foo --no-frotz" to
countermand the frotz option, and by marking the boolean frotz
option to be a NONEG, you can forbid such a usage.  That is the only
"use case" I can think of, and that particular use case does not
sound like a valid one.

Looking at "git grep -B3 OPT_NONEG" output, it seems that NONEG is
associated mostly with OPTION_CALLBACK and OPTION_SET_INT in the
existing code.

Perhaps OPT_SET_INT should default to not just OPT_NOARG but also
OPT_NONEG?

I have a suspition that most users of other OPT_SET_<TYPE>
short-hands may also want them to default to NONEG (and the rare
ones that want to allow "--no-value-of-this-type=Heh" for some
reason to use the fully spelled form).  IIRC NONEG is relatively a
new addition, and many existing OPT_STRING() may predate it.

So I am not sure if doubling the number of OPT_<type> macros as your
micro suggestion proposes is the right solution to the problem.

Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG

[Duy Nguyen]

On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Looking at "git grep -B3 OPT_NONEG" output, it seems that NONEG is
> associated mostly with OPTION_CALLBACK and OPTION_SET_INT in the
> existing code.
>
> Perhaps OPT_SET_INT should default to not just OPT_NOARG but also
> OPT_NONEG?

There are OPT_SET_INT() that should not have NONEG in current code. So
there are two sets of SET_INT anyway. Either we convert them all to a
new macro that takes an extra flag, or we add OPT_SET_INT_NONEG() that
covers one set and leave the other set alone.

> I have a suspition that most users of other OPT_SET_<TYPE>
> short-hands may also want them to default to NONEG (and the rare
> ones that want to allow "--no-value-of-this-type=Heh" for some
> reason to use the fully spelled form).  IIRC NONEG is relatively a
> new addition, and many existing OPT_STRING() may predate it.

I haven't checked how NONEG affects other types. But that's something
I should probably look into.
-- 
Duy

Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Looking at "git grep -B3 OPT_NONEG" output, it seems that NONEG is
>> associated mostly with OPTION_CALLBACK and OPTION_SET_INT in the
>> existing code.
>>
>> Perhaps OPT_SET_INT should default to not just OPT_NOARG but also
>> OPT_NONEG?
>
> There are OPT_SET_INT() that should not have NONEG in current code. So
> there are two sets of SET_INT anyway. Either we convert them all to a
> new macro that takes an extra flag, or we add OPT_SET_INT_NONEG() that
> covers one set and leave the other set alone.

Are you forgetting the third alternative, of swapping the default,
if the ones that do not want NONEG are in the minority, to reduce
the number of spelled-out instances?

Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG

[Duy Nguyen]

On Fri, Mar 14, 2014 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Looking at "git grep -B3 OPT_NONEG" output, it seems that NONEG is
>>> associated mostly with OPTION_CALLBACK and OPTION_SET_INT in the
>>> existing code.
>>>
>>> Perhaps OPT_SET_INT should default to not just OPT_NOARG but also
>>> OPT_NONEG?
>>
>> There are OPT_SET_INT() that should not have NONEG in current code. So
>> there are two sets of SET_INT anyway. Either we convert them all to a
>> new macro that takes an extra flag, or we add OPT_SET_INT_NONEG() that
>> covers one set and leave the other set alone.
>
> Are you forgetting the third alternative, of swapping the default,
> if the ones that do not want NONEG are in the minority, to reduce
> the number of spelled-out instances?
>

There are 12 SET_INT with NONEG and 81 without (though I suspect some
of them should have NONEG). So NONEG is not exactly the majority. And
swapping does not go well with git development style, some in-flight
topics may introduce new OPT_SET_INT() that uses the old behavior.


-- 
Duy