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