MIME-Version: 1.0
References: <00e701cf7542$114f8870$33ee9950$@post.harvard.edu>
            <537DA7E9.7080403@morningstar2.co.uk>
            <010801cf759c$84533fb0$8cf9bf10$@post.harvard.edu>
Content-Type: text/plain; charset=UTF-8
Message-ID:  <CANQYN6xxUNg9VC3O8A4n8ZA-o2K=dR0npwECnkg10rr8R+JC5Q@mail.gmail.com>
Date:         Thu, 29 May 2014 20:05:41 -0400
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: Trouble with the .bool_set:N property
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <010801cf759c$84533fb0$8cf9bf10$@post.harvard.edu>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 5/22/14, pintar@post.harvard.edu <pintar@post.harvard.edu> 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