{"thread":{"id":"36082","subject":"Microproject idea: new OPT_* macros for PARSE_OPT_NONEG","startedAt":"2014-03-07T01:38:26Z","lastAt":"2014-03-13T23:34:21Z","messageCount":7,"participants":["Duy Nguyen","Michael Haggerty","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"236230","messageId":"CACsJy8CBVVJN3V8N_djLF4XKfTbxvdcJCnWmZJxVZOwy8AMQWA@mail.gmail.com","threadId":"36082","inReplyTo":null,"subject":"Microproject idea: new OPT_* macros for PARSE_OPT_NONEG","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-07T01:38:26Z","receivedAt":"2014-03-07T01:38:26Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Currently in order to avoid --[no]-xxx form we have to resort to\ndeclare full struct option. It'd be nice to have a set of OPT_* macros\nwith PARSE_OPT_NONEG set. Find and update all \"struct option []\"\ndeclarations with the new macros (including ones that should never\naccept --no- form, but do anyway).\n-- \nDuy\n"},{"id":"236251","messageId":"531977AF.4060907@alum.mit.edu","threadId":"36082","inReplyTo":"CACsJy8CBVVJN3V8N_djLF4XKfTbxvdcJCnWmZJxVZOwy8AMQWA@mail.gmail.com","subject":"Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-03-07T07:39:27Z","receivedAt":"2014-03-07T07:39:27Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/07/2014 02:38 AM, Duy Nguyen wrote:\n> Currently in order to avoid --[no]-xxx form we have to resort to\n> declare full struct option. It'd be nice to have a set of OPT_* macros\n> with PARSE_OPT_NONEG set. Find and update all \"struct option []\"\n> declarations with the new macros (including ones that should never\n> accept --no- form, but do anyway).\n\nI added this to the list, with the following warning:\n\n This is more a milliproject than a microproject\n\nbecause to me it feels considerably more involved than the other\nmicroprojects. To complete it, the student will have to understand at\nleast part of the parse_options() API, which is more than a 15 minute\njob by itself.\n\nThanks,\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"236253","messageId":"CACsJy8AUhHE8=Yaj6_G46V6w5ZbA3z403GkBfsbZL7MxgeA3RQ@mail.gmail.com","threadId":"36082","inReplyTo":"531977AF.4060907@alum.mit.edu","subject":"Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-07T07:54:12Z","receivedAt":"2014-03-07T07:54:12Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Mar 7, 2014 at 2:39 PM, Michael Haggerty wrote:\n> On 03/07/2014 02:38 AM, Duy Nguyen wrote:\n>> Currently in order to avoid --[no]-xxx form we have to resort to\n>> declare full struct option. It'd be nice to have a set of OPT_* macros\n>> with PARSE_OPT_NONEG set. Find and update all \"struct option []\"\n>> declarations with the new macros (including ones that should never\n>> accept --no- form, but do anyway).\n>\n> I added this to the list, with the following warning:\n>\n> This is more a milliproject than a microproject\n>\n> because to me it feels considerably more involved than the other\n> microprojects. To complete it, the student will have to understand at\n> least part of the parse_options() API, which is more than a 15 minute\n> job by itself.\n\nI don't know the scope of these microprojects, but yes I think it'll\ntake a few hours for this. By the way, a bit more thought on the idea:\ninstead of making OPT_BOOL_NONEG() that sets NONEG, we could make\nOPT_BOOL_FLAGS(..., NONEG), which is more flexible.\n-- \nDuy\n"},{"id":"236270","messageId":"xmqqzjl1u87n.fsf@gitster.dls.corp.google.com","threadId":"36082","inReplyTo":"CACsJy8AUhHE8=Yaj6_G46V6w5ZbA3z403GkBfsbZL7MxgeA3RQ@mail.gmail.com","subject":"Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-07T19:20:12Z","receivedAt":"2014-03-07T19:20:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> I don't know the scope of these microprojects, but yes I think it'll\n> take a few hours for this. By the way, a bit more thought on the idea:\n> instead of making OPT_BOOL_NONEG() that sets NONEG, we could make\n> OPT_BOOL_FLAGS(..., NONEG), which is more flexible.\n\nWhat does a boolean that can never be set to false achieve, by the\nway? If you have\n\n [alias]\n foo = bar --frotz\n\nthen you may want to be able to say \"git foo --no-frotz\" to\ncountermand the frotz option, and by marking the boolean frotz\noption to be a NONEG, you can forbid such a usage. That is the only\n\"use case\" I can think of, and that particular use case does not\nsound like a valid one.\n\nLooking at \"git grep -B3 OPT_NONEG\" output, it seems that NONEG is\nassociated mostly with OPTION_CALLBACK and OPTION_SET_INT in the\nexisting code.\n\nPerhaps OPT_SET_INT should default to not just OPT_NOARG but also\nOPT_NONEG?\n\nI have a suspition that most users of other OPT_SET_\nshort-hands may also want them to default to NONEG (and the rare\nones that want to allow \"--no-value-of-this-type=Heh\" for some\nreason to use the fully spelled form). IIRC NONEG is relatively a\nnew addition, and many existing OPT_STRING() may predate it.\n\nSo I am not sure if doubling the number of OPT_ macros as your\nmicro suggestion proposes is the right solution to the problem.\n"},{"id":"236648","messageId":"CACsJy8Dw=43m_4KzAxwCqLsFq2E23rT=bT3zmGUue6RYTnrOYg@mail.gmail.com","threadId":"36082","inReplyTo":"xmqqzjl1u87n.fsf@gitster.dls.corp.google.com","subject":"Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-12T23:37:41Z","receivedAt":"2014-03-12T23:37:41Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano wrote:\n> Looking at \"git grep -B3 OPT_NONEG\" output, it seems that NONEG is\n> associated mostly with OPTION_CALLBACK and OPTION_SET_INT in the\n> existing code.\n>\n> Perhaps OPT_SET_INT should default to not just OPT_NOARG but also\n> OPT_NONEG?\n\nThere are OPT_SET_INT() that should not have NONEG in current code. So\nthere are two sets of SET_INT anyway. Either we convert them all to a\nnew macro that takes an extra flag, or we add OPT_SET_INT_NONEG() that\ncovers one set and leave the other set alone.\n\n> I have a suspition that most users of other OPT_SET_\n> short-hands may also want them to default to NONEG (and the rare\n> ones that want to allow \"--no-value-of-this-type=Heh\" for some\n> reason to use the fully spelled form). IIRC NONEG is relatively a\n> new addition, and many existing OPT_STRING() may predate it.\n\nI haven't checked how NONEG affects other types. But that's something\nI should probably look into.\n-- \nDuy\n"},{"id":"236682","messageId":"xmqqfvmlj54n.fsf@gitster.dls.corp.google.com","threadId":"36082","inReplyTo":"CACsJy8Dw=43m_4KzAxwCqLsFq2E23rT=bT3zmGUue6RYTnrOYg@mail.gmail.com","subject":"Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-13T19:00:24Z","receivedAt":"2014-03-13T19:00:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano wrote:\n>> Looking at \"git grep -B3 OPT_NONEG\" output, it seems that NONEG is\n>> associated mostly with OPTION_CALLBACK and OPTION_SET_INT in the\n>> existing code.\n>>\n>> Perhaps OPT_SET_INT should default to not just OPT_NOARG but also\n>> OPT_NONEG?\n>\n> There are OPT_SET_INT() that should not have NONEG in current code. So\n> there are two sets of SET_INT anyway. Either we convert them all to a\n> new macro that takes an extra flag, or we add OPT_SET_INT_NONEG() that\n> covers one set and leave the other set alone.\n\nAre you forgetting the third alternative, of swapping the default,\nif the ones that do not want NONEG are in the minority, to reduce\nthe number of spelled-out instances?\n"},{"id":"236698","messageId":"CACsJy8C5QtgPNxoBvF5nxs47rD1MGgL+2nkZ3WONB6iBZkbyAw@mail.gmail.com","threadId":"36082","inReplyTo":"xmqqfvmlj54n.fsf@gitster.dls.corp.google.com","subject":"Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-13T23:34:21Z","receivedAt":"2014-03-13T23:34:21Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Mar 14, 2014 at 2:00 AM, Junio C Hamano wrote:\n> Duy Nguyen writes:\n>\n>> On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano wrote:\n>>> Looking at \"git grep -B3 OPT_NONEG\" output, it seems that NONEG is\n>>> associated mostly with OPTION_CALLBACK and OPTION_SET_INT in the\n>>> existing code.\n>>>\n>>> Perhaps OPT_SET_INT should default to not just OPT_NOARG but also\n>>> OPT_NONEG?\n>>\n>> There are OPT_SET_INT() that should not have NONEG in current code. So\n>> there are two sets of SET_INT anyway. Either we convert them all to a\n>> new macro that takes an extra flag, or we add OPT_SET_INT_NONEG() that\n>> covers one set and leave the other set alone.\n>\n> Are you forgetting the third alternative, of swapping the default,\n> if the ones that do not want NONEG are in the minority, to reduce\n> the number of spelled-out instances?\n>\n\nThere are 12 SET_INT with NONEG and 81 without (though I suspect some\nof them should have NONEG). So NONEG is not exactly the majority. And\nswapping does not go well with git development style, some in-flight\ntopics may introduce new OPT_SET_INT() that uses the old behavior.\n\n\n-- \nDuy\n"}]}