Morten Høgholm wrote: > On Sat, Sep 6, 2008 at 9:43 AM, Joseph Wright > <[log in to unmask]> wrote: > >> I've been looking at the current expl3 work, and I'm wondering about the >> planned direction with keyval stuff. The current l3keyval only covers >> some very basic functions, and it's not clear to me whether this will be >> extended to higher-level commands. > > It will. So far only data extraction was done because a) it was needed > and b) I need to sit down, preferably with someone, and take a good > look at how to tackle this. Judging from the hacks we see in pstricks > and many other packages, the current approach as implemented in keyval > is insufficient. The model used in pgf looks interesting. I agree. I think overall the idea of separating "properties" of keys is much bettr than (say) xkeyval. > > How the keyvals are used depends on the circumstances. If you take a > look at template, it both runs traditional "turn key into csname, then > assign it a value" but also contains a more complex run when declaring > the template. In the latter instance, the value in fact consists of > individual values, each requiring different action. That might be a challenge. I was mainly thinking about providing a way for programmers to set up options, etc. I suspect template will push everything. >> [snip] if no-one else is likely to >> work on this in the near future I can perhaps see whether I can produce >> some basic macros in this area (for preference I'd probably adopt the >> pgfopts model, which I find quite accessible). > > Please do go ahead. > Okay, I will have a look at this. For first preference, I might use the pgfopts syntax: /<module>/<description>/.<property> although I suppose: <module>_<description>.<property> or <module>_<description>:<property> might both be more in line with the LaTeX3 system. However, I think the analogy with UNIX paths works quite nicely for the pgfopts approach. -- Joseph Wright