Subject: | |
From: | |
Reply To: | |
Date: | Sun, 6 Mar 2011 11:47:22 +0100 |
Content-Type: | multipart/signed |
Parts/Attachments: |
|
|
Joseph Wright wrote:
> On 06/03/2011 07:47, Frank Mittelbach wrote:
>> > It's not 100 clear yet, but the initial plan at least for me is that
>> > coffins are a design-level construct. That means that \NewCoffin is the
>> > way to produce coffins - \coffin_new:N is there mainly to be wrapped up
>> > in a design-level function.
>> >
>> > Perhaps you might illustrate what you're doing at a 'concept' level?
>>
>> in my opinion it should be there, so I would call it an oversight.
>>
>> On document level, you are right, \NewCoffin should be enough but if you build
>> a package that involves coffins it is possible that the names of that coffin
>> are build from other structures, so that you wan to use :c to produce them
Yes, that's exactly my case here. To be more verbose, I want to do
something like (pseudo code):
for i = 1,30 do
\coffin_new:c{pkg i coffin}
end
to generate 30 individual coffins that later can be adressed and
processed in the same way.
Frank, thanks for pointing me at \cs_generate_variant:Nn; I already
foudn it but was not sure if this was the best way to go.
> When I rewrote the coffins code, I originally included "c" variants, but
> decided to leave them out pending seeing whether they were needed. I've
> no objection to them, I was just trying to avoid 'variant overkill'.
> Note that if you allow "c"-type names, then it's not just \coffin_new:N
> that needs variants. All of the 'code-level interface' functions should
> be done for consistency. This is the work of 5 minutes: shall I make the
> change?
If no one else has needed it so far, I'll just add it to my package. I
only asked to see if there was a special reason that coffin names should
not be handled this way.
Thanks for your replies,
Arno
|
|
|