LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-Transfer-Encoding: 7bit
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
From: Joseph Wright <[log in to unmask]>
Date: Sat, 5 Sep 2009 09:02:56 +0100
Content-Type: text/plain; charset=ISO-8859-1
MIME-Version: 1.0
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (44 lines)
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.
-- 
Joseph Wright

ATOM RSS1 RSS2