User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4A2F5FE3.3030205@morningstar2.co.uk>
Date:         Wed, 10 Jun 2009 08:25:23 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Key-value input
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Precedence: list
Status: R

Hello all,

A while ago, I wrote the "keys3" package as an experiment in how
key-value methods might be implemented in LaTeX3. I've done various
refinements on the code to try to make it clear, but I'm not sure I've
succeeded.  So I'm thinking about the problem again.

For LaTeX2e, key-value input can be created in two broad ways:

- Using a key-by-key approach with dedicated macros. This is the method
used in keyval itself, xkeyval and kvoptions.
- Using a keyval list to create keys. This is what pgfkeys does, and
what I followed when creating keys3.

I note that the current template code also uses the second approach. The
complexity of xkeyval, in particular, really makes me think that some
kind of keyval method for generating keys is the best plan. So it is
then a question of the best way to do that.

I wonder if the pgfkeys idea of using one macro to create and set keys
is confusing. Currently, it is what I've done in keys3:

  \keys_manage:n{
    % Some keys are created
  }
  \keys_manage:n{
    % Some keys are set
  }

but do other people think that strict separation:

  \keys_generate:n {
    % Some keys are created
  }
  \keys_set:n {
    % Some keys are set
  }

is clearer?

The other question is how to make keys in this way. keys3 uses the idea
of properties:

  key name/.property = value

for example

  \module\my~key/.tl_set:N  = \l_module_my_tl,
  \module\my~key/.default:n = {default}

to create a key which will store its input in a tl. On the other hand,
template uses and "extended key-value" approach:

key name =<type> [default] <function>

for example:

  my key =n [default] \l_module_my_tl

Both ideas have some good points. template keeps everything in one line,
which probably makes it easier to see what goes with what. On the other
hand, the pgfkeys approach does not need any special layout of the input
to work.

I wonder how other people see the two schemes, and if there are other
ways that similar effects can be achieved.
-- 
Joseph Wright