MIME-Version: 1.0
References: <CAFUtaNEDNgmniEKBn5Oe8=+S2PiZTe7=1HK7XQLq0cq0e8iu-g@mail.gmail.com>
            <CANQYN6xOonzhCqc34MrGqNouVbvdXOshkLxjbpkSrqSzwMGG6Q@mail.gmail.com>
            <CAFUtaNHj4YpS2kRn5OEyf1CLftNA7ZtaVfb698PsBYCLfJHCbg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Message-ID:  <CANQYN6yyxhkOYODFsKmjoJ6ZsJLcDDnqyqVQXjvWpUS0xZT=DA@mail.gmail.com>
Date:         Tue, 9 Jul 2013 19:45:55 -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: Named options/enumerations (Was re: Defining \bool_case:nn)
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CAFUtaNHj4YpS2kRn5OEyf1CLftNA7ZtaVfb698PsBYCLfJHCbg@mail.gmail.com>
Precedence: list
Content-Transfer-Encoding: quoted-printable
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Hello,

>>     \keys_define:nn { jcsfonts }
>>       {
>>         font .choice: ,
>>         font / cmodern .code:n =3D { } ,
>>         font / kpfonts .code:n =3D { \RequirePackage{kpfonts} } ,
>>       }
>
> The code in the various options is more than a single line =97 about te=
n
> lines per option, actually, and it seems messy to intertwine option
> processing with option execution like that.

Ok.

>> I don't really get the issue with \str_case:Vnn, to be honest, and I
>> don't see the advantage of an enum type.  Given that it makes the
>> syntax much more verbose, I am so far not convinced.
> <snip>
>> An enum type seems to only be useful if it is significantly more
>> efficient than a property list ("associative array"/"dictionary") with
>> empty values.
>
> I'm not fixated on enumerations, but I don't see how a property list is=
 at
> all the same thing. A enum object is one that can only take one of a
> restricted list of values; in C it's basically a thinly-disguised integ=
er,
> combined with a list of integer constants. In expl3 it could be integer=
s or
> quarks (as in my bizarre idea above), whichever works better. (Or neith=
er,
> if the need for such a type is not there.)
>
> Could you please explain what you meant?

Since we have no type checking (and no object-oriented code, really),
it seems to me that an enum variable can simply be manipulated as a
string (tl, since l3str is not yet in l3kernel).  What do people want
to do with an enum?  (1) Make sure that its value is indeed in the
correct list: for this one can keep track of a fixed set of allowed
values, and since expl3 has no 'set' datatype, one can use a prop with
empty values.  (2) Make a case statement: this can either be done with
\str_case, or with a prop having the same keys but non-empty values
(giving the appropriate code to run).  (3) ...?

I am probably missing some of the use for enums, but so far I haven't
seen a clear example of need.  Also, since l3obj is not yet even
drafted, it is difficult to say "go forth and implement that
datatype", as it would be nicer/more useful if there was some proper
object-oriented support in expl3 (ok, I think I'm the only one pushing
for more of that in expl3).

Does that explain a bit?
Bruno