Will Robertson wrote:
> In everything below, I'm especially trying to ignore the syntax of the
> template definitions entirely; I think the two points I raise below are
> fairly independent to whether we use letters or tokens or whatever to
> define the template keytypes.
Seems reasonable provided we always end up with the same functionality
(which is the plan).
> That is, we should offer something that looks like template's
>
> above-skip =L [0pt] \l_caption_above_skip ,
> number-format =f2 [#1~#2:~] \caption_number_format:nn ,
>
> as well as providing a function such as
>
> \DeclareTemplateDefaults{type}{template}{
> above-skip = 0pt ,
> number-format = {#1~#2:~} ,
> }
>
> Template authors may then use one or the other as appropriate for the
> application, and users of layer 1 can use the function to help create
> their instances.
>
> PROPOSAL: Whatever the interface itself, both ways of setting defaults
> should be offered. (And whether it's optional or not, per Joseph's
> recent post, is still up for debate.)
This seems reasonable to me: I'll be interested to see how we end up
coding it :-)
> above-skip .skip_set:Nn = \l_caption_above_skip {0pt} ,
> number-format .func_2_args:Nn = \caption_number_format:nn {#1~#2:~},
>
> I would prefer to write
>
> above-skip .set:Nn = \l_caption_above_skip {0pt} ,
> number-format .set:Nn = \caption_number_format:nn {#1~#2:~},
A bit more challenging than my current implementation! However, quite
doable I think.
> On this point, Frank wrote:
>> - the key settings more or less completely hide the nature of the key, eg
>> .functions:N means a function is expected (in contrast to a variable of
>> some kind) but it is not clear what kind of function is needed or
>> what kind
>> of variable is expected
>
> I don't understand this, sorry. If I write '=f2' then I don't know what
> kind of function is needed (unless you mean the number of arguments?
> Which follows from the function name...), and if I write '.set:Nn
> \l_caption_above_skip' then it's clear that we're setting a length
> register...so in both cases I don't follow your criticism. (But I'm
> probably misunderstanding your point.)
I suspect Frank means that with something like
number-format =f2 [#1~#2:~] \caption_number_format:nn
you can look down the columns to see the "type" of key being defined
without needing to understand the definition itself. So here you can see
that a function with two arguments is being set up without needing to
know that :nn also indicates this.
> Aside: The other reason I like implicit .set:Nn is for
> "extra variable/data types". If Joseph were to invent an
> expnum datatype that allowed input like '3e-4' for siunitx
> then (and we allowed this sort of thing) template
> definitions would be able to use the corresponding
> \expnum_set:Nn function without adding any extra code
> (or letters to remember) to template itself.
> (For this to work, each datatype would have to declare
> itself in a property list with a name and functions for
> using it. Not sure if it's just a crazy idea or something
> useful, at this stage of the day.)
Aside: At some point I need to sort out floating-point numbers, and
there I may well want a _fp variable type. So the idea is more than
theoretical.
> OPTIONS:
> 1. Only explicit keytypes (no automagic) like template is now
> 2. Only implicit keytypes like template-alt is now
> 3. Both of the above
>
> I'd like to propose option #3 not because I like "automagic" but because
> I believe it will help to simplify the interface, while still providing
> "plain" keytypes for those cases where the disambiguation is necessary.
I'm happy with this also. (As with \cs_set:Nn, the simplification does
seem worth it to me.)
> These are only two points, but I hope we can decide on them before
> moving onto the next troublesome parts. As I said, I'm trying to ignore
> the interface at this stage so I don't care if the default is optional
> or not or before the variable or after it; similarly, all I care about
> with the different keytypes is that we need a bunch of them for
> different variables and other things, not what they're called or what
> they look like.
>
> So the big question is: can we agree on the two points raised above,
> first? :)
Well I'm happy.
--
Joseph Wright
|