Subject: | |
From: | |
Reply To: | |
Date: | Tue, 23 Aug 2011 19:29:10 +0200 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Am Tue, 23 Aug 2011 17:39:18 +0100 schrieb Joseph Wright:
>>> Well no, as the special 'unknown' key allows behaviour for a key which
>>> is not defined to be set up.
>> Does keys_set_known makes a difference between modules with and
>> without such an unknown key?
> The current approach is that \keys_set_known:nnN only sets
> explicitly-defined keys. So it does not matter if a set of keys have an
> 'unknown' value or not. (I'm not quite clear why you'd want to do
> \keys_set_known:nnN with an 'unknown' value set if this meant that there
> was no difference to just using \keys_set:nn.)
I didn't want to do something, I only tried to understand the "side
effects" of using the "unknown" key.
>
>> I'm currently changing chessfss to keyval-syntax. I have to set
>> properties for board fonts, figurines fonts and other symbols. So I
>> have a structure like this:
>>
>> all chess fonts
>> family
>> width
>> series
>> size
>>
>> fig font
>> encoding
>> family
>> width
>> series
>> size
>>
>> board font
>> encoding
>> family
>> width
>> series
>> size
>>
>> ...
>>
>> So keys like "fig / encoding" look quite natural, but it would be
>> quite useful if a user could set keys also like this:
>>
>> set-all, family=...
>>
>> set-fig, family=... , size= ...
> At a technical level, this can be supported. However, my concern is more
> at the conceptual level. In most programming languages, keyval input is
> used to replace positional parameters by named ones. On the other hand,
> the pgfkeys approach inter-mixes named parameters with executed items.
chessboard is doing it too. Once I got the knack on defining keys it
came quite naturally to use them not only to set width or size but
also to put and remove pieces, declare a color in one key, and with
the next key draw a rule in this color.
I realized only at the end that this was an quite unusual use of
keyval syntax.
A "change path" command would be really useful here. Currently every
key must have an unique name, and this can give quite long names.
> At present, the approach in l3keys when setting keys is rather more
> toward the 'named parameters' approach.
This is also the case with xkeyval and it could be used for the
other approach too ;-) I think l3keys is very powerful and quite fun
to use.
--
Ulrike Fischer
|
|
|