On 5/22/14, [log in to unmask] <[log in to unmask]> wrote: >> It's a bit more complicated than that :-) > > It usually is! > >> If you look at the code, any case where someone sets up a 'choice of > choices' >> will fail. That's not good, and so before any worries about booleans >> specifically I'll fix this more general issue. My feeling is that trying > to set up a >> 'choice of choices' key is an error in the definition rather than at >> point > of use, >> so I'm minded to trap such cases and issue a error message. Does that > sound >> reasonable? For example, what is something like >> >> key-1 .choice: , >> key-1 / choice-a .choice: , >> key-1 / choice-a / value-1 .code = ... >> >> actually going to achieve? > > Yes, I'd noticed that it will fail (I actually mentioned it in passing in > the > tex.stackexchange discussion), but it didn't worry me so much precisely > because > I couldn't think of any reason why one would want to set up a case like > that. > Of course, it's definitely better if attempts to do so raised an error > instead > of getting stuck in a loop! > >> One the specifics of boolean keys, I can see the point here about >> set_true/set_false as they match 'normal' variable setting. On the other >> hand, the original design here was to recognise that a boolean key is >> somewhat 'special': it is a choice from a limited range of values. >> Moreover, my thinking was that enforcing "true"/"false" as the values >> avoided the possible need for people to allow for "on"/"off" or >> "yes"/"no" >> (I've worried about this in the past). It was also meant to indicate that > a >> boolean key should be one that 'reads' as >> >> <thing> = (true|false) >> >> rather than >> >> <thing> = (foo|bar) >> >> as that seems less useful to the end user (if the options are more >> complex >> than true/false then some other description is needed at the >> documentation >> level anyway). > > I see your point, but I can also imagine cases where at the user end it > might > feel more natural to have something like > > \mymoduledoclevelsetup{ turnfooingon } > \mymodulecoclevelsetup{ turnfooingoff } > > instead of > > \mymoduledoclevelsetup{ fooing = true } > \mymoduledoclevelsetup{ fooing = false } > > I guess the decision here is really between nudging package authors towards > uniformity and trusting them to develop a syntax that's best for their > target > users on their own (it's not exactly imposing uniformity, because a package > > writer stubborn enough could always type the few extra characters to get > " turnfooingon .code:n = { \bool_set_true:N \l_mymodule_fooing_bool } "). Wait, how is that not covered by .bool_set:N and .bool_set_inverse:N? Doing " turnfooingon .bool_set:N = \l_mymodule_fooing_bool " and " turnfooingoff .bool_set_inverse:N = \l_mymodule_fooing_bool " allows the user to use the keys turnfooingon and turnfooingoff as you describe. Well, it also allows the user to do weirder things like "turnfooingoff=false" to turn fooing on. Bruno