Hello, >> \keys_define:nn { jcsfonts } >> { >> font .choice: , >> font / cmodern .code:n = { } , >> font / kpfonts .code:n = { \RequirePackage{kpfonts} } , >> } > > The code in the various options is more than a single line — about ten > 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 integer, > combined with a list of integer constants. In expl3 it could be integers or > quarks (as in my bizarre idea above), whichever works better. (Or neither, > 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