Joseph Wright wrote: > Hello all, > > The ongoing template discussion has prompted me to think again about > some aspects of l3keys. It's pretty clear to me that the aims in l3keys > are rather different from those in template. l3keys is really about > creating keys for the programmer, so it can take a very different > approach to template. > > Several things have come up in the discussion, and I'd like to see how > other people feel about the following before doing anything: > > - I added .initial:n and .initial:V mainly with template in mind. In > l3keys, initial values can be set using \keys_set:nn, and overall I feel > this is probably clearer (separate key definition from key setting). I'd > therefore like to drop .initial:n/V > > - There is .function:N which again was more about template than l3keys. > I'm not sure the property is actually very clear (it does \cs_set:Nn > <function> { <key-value }), so again I'd like to remove it. > > - There are currently a .code:n and a .code:Nn property, where the > former only takes one argument and the later takes N. To be honest, I > think it might be better to only have .code:n so that if further > splitting of a value is needed it is done elsewhere, and not by l3keys. > > - Related to the .code:Nn point, .generate_choices:nn also splits the > value part of a key-value argument in two. I'm no longer sure this is a > good thing, so perhaps > .choice_code:n = <code>, > .generate_choices:n = <choices> > would be better. > > - Not everyone likes the .set:N idea of detecting the variable type and > scope from the variable name, rather than having .tl_set:N, .int_gset:N, > etc. As we are talking about a programmer function, it's not > unreasonable to read the variable information from the name. It's easy > to go back to the previous method if that is the consensus. > > I'd like to get this sorted out soon (i.e. in the next week) as I am > using l3keys for siunitx v2 and as Manuel has indicated he is also > looking at using l3keys for real work. I've made the changes outlined above. At present, I've retained .set:N and added - .dim_(g)set:N - .int_(g)set:N - .skip_(g)set:N - .tl_(g)set:N - .tl_(g)set_x:N Is everyone OK with retaining .set:N in this way, or would others prefer only to have the explicit setting properties? I'd like to update the CTAN version soon to reflect these changes (which I hope are the final ones for l3keys), and so want to get this right. -- Joseph Wright