Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG
On Fri, Mar 14, 2014 at 2:00 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG
Duy Nguyen writes: > On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG
On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano 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_ > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG
Duy Nguyen 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_ 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_ macros as your micro suggestion proposes is the right solution to the problem. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG
On Fri, Mar 7, 2014 at 2:39 PM, Michael Haggerty 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG
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 mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Microproject idea: new OPT_* macros for PARSE_OPT_NONEG
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
