On Jul 8, 2013 10:33 PM, "Bruno Le Floch" <[log in to unmask]> wrote: > > Hello Joel, > > Surely Joseph will have something to say about the topic (he is > currently doing some changes to l3keys), but let me try. I've seen some of the changes already on GitHub, and they look like they'll make life simpler. > > This use of named options feels like it should be reasonably common in > > user-facing code, but Expl3 doesn’t have an obvious way of managing this. > > > > \keys_define:nn { jcsfonts } > > { font .choice_code:n = \tl_gset:NV \g_jcsfonts_option_tl > > \l_keys_choice_tl } > > > > \str_case:Vnn \g_jcsfonts_option_tl > > { { cmodern } {} % Computer Modern is LaTeX default > > { kpfonts } { \RequirePackage{kpfonts} } > > } { \msg_error… } > > What about > > \keys_define:nn { jcsfonts } > { > font .choice: , > font / cmodern .code:n = { } , > font / kpfonts .code:n = { \RequirePackage{kpfonts} } , > } > > This will trigger a "key-choice-unknown" error upon encountering an > unknown choice (well, right now the message is not defined... that'll > be fixed). Maybe we could add a feature to allow arbitrary code for > unknown choices. 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. > > I recently asked “Can I refer to key value in general code?” ( > > http://tex.stackexchange.com/q/120258/2966). My initial thought (somewhat > > bizarre, I’ll admit) was to save the option is a quark, set equal to one of > > a group of quarks. > > I think that code was missing at least one "_". Does my answer there help you? I didn't get a chance to look at it closely, but the basic idea of combining property lists and key options feels “right", and would provide the decoupling I'm looking for. > 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? —Joel