Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f0V83g715990 for ; Wed, 31 Jan 2001 09:03:42 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f0V84Q730395 . for ; Wed, 31 Jan 2001 09:04:30 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f0V83b702069 for ; Wed, 31 Jan 2001 09:03:37 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08B5C.53780300" Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id JAA06126 for ; Wed, 31 Jan 2001 09:03:37 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f0V83aM25287 for ; Wed, 31 Jan 2001 09:03:37 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <2.2711324D@mail.listserv.gmd.de>; Wed, 31 Jan 2001 9:03:33 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 485120 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Wed, 31 Jan 2001 09:03:32 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id JAA12792 for ; Wed, 31 Jan 2001 09:03:31 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id JAA35780 for ; Wed, 31 Jan 2001 09:03:30 +0100 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f0V83Sp00873 for ; Wed, 31 Jan 2001 09:03:28 +0100 (MET) Received: from [195.20.224.208] (helo=mrvdom01.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14NsEh-0007Be-00 for LATEX-L@urz.uni-heidelberg.de; Wed, 31 Jan 2001 09:03:27 +0100 Received: from manz-3e36472c.pool.mediaways.net ([62.54.71.44] helo=istrati.zdv.uni-mainz.de) by mrvdom01.schlund.de with esmtp (Exim 2.12 #2) id 14NsEe-0000tc-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Wed, 31 Jan 2001 09:03:24 +0100 Received: (from latex3@localhost) by istrati.zdv.uni-mainz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id JAA32110; Wed, 31 Jan 2001 09:01:34 +0100 In-Reply-To: References: Return-Path: X-Mailer: VM 6.75 under Emacs 20.4.1 X-Authentication-Warning: istrati.zdv.uni-mainz.de: latex3 set sender to frank@mittelbach-online.de using -f Content-class: urn:content-classes:message Subject: Re: Templates (collection instances) Date: Wed, 31 Jan 2001 09:01:34 +0100 Message-ID: <14967.50782.287064.421256@istrati.zdv.uni-mainz.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3677 This is a multi-part message in MIME format. ------_=_NextPart_001_01C08B5C.53780300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Perhaps a straightforward unprotected \edef isn't right, but a > \protected@edef would let through a lot of things which are bad too. > Perhaps the right thing would be some kind of \protect@is@error@edef. shouldn't that be, for the purpose you have in mind rather \protect@is@string@edef perhaps? i mean is the purpose is to make a "proper" latex internally usable name = then stringing things is probably the way to go, or not? > >that would be an alternative, but again I would like to see at least = a single > >example why one would need/want expansion (beside gut feeling, = though the > >latter might be useful) > > First example: The name value is a mangled general text; then you = don't > want to mangle it anew each time you use it (especially since you = don't > know the conditions then will be), but have it stored in a mangled = form. maybe, but could you be more specific in the example, please? i mean can = you really see a practical need (not an abstract one) > Second example: I suspect that there will be a number of instances = declared > where at least some of the key values get set to the current value of = some > LaTeX parameter (one could argue that this is bad programming, but = this > kind of thing is sometimes hard to avoid). is it really hard to avoid or is it only the way we are used to write = classes (like using \baselineskip and later on changing it and not noticing that = they are different). in some sense it means that you define sort of meta variables or rather = "class constants" that you set near the top and then reuse. There is something = to that as it (if done carefully) helps to structure your template = instantiations and give them some sort of extra flexibility. on the other hand if one does that too much you get another hierachy = into the layout process which is difficult to understand. but that doesn't really mean one shouldn't offer it. frank ------_=_NextPart_001_01C08B5C.53780300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Templates (collection instances)

 > Perhaps a straightforward unprotected \edef = isn't right, but a
 > \protected@edef would let through a lot of = things which are bad too.
 > Perhaps the right thing would be some kind = of \protect@is@error@edef.

shouldn't that be, for the purpose you have in mind = rather
\protect@is@string@edef perhaps?

i mean is the purpose is to make a "proper" = latex internally usable name then
stringing things is probably the way to go, or = not?


 > >that would be an alternative, but again = I would like to see at least a single
 > >example why one would need/want = expansion (beside gut feeling, though the
 > >latter might be useful)
 >
 > First example: The name value is a mangled = general text; then you don't
 > want to mangle it anew each time you use = it (especially since you don't
 > know the conditions then will be), but = have it stored in a mangled form.

maybe, but could you be more specific in the example, = please? i mean can you
really see a practical need (not an abstract = one)

 > Second example: I suspect that there will = be a number of instances declared
 > where at least some of the key values get = set to the current value of some
 > LaTeX parameter (one could argue that this = is bad programming, but this
 > kind of thing is sometimes hard to = avoid).

is it really hard to avoid or is it only the way we = are used to write classes
(like using \baselineskip and later on changing it = and not noticing that they
are different).

in some sense it means that you define sort of meta = variables or rather "class
constants" that you set near the top and then = reuse. There is something to
that as it (if done carefully) helps to structure = your template instantiations
and give them some sort of extra flexibility.

on the other hand if one does that too much you get = another hierachy into the
layout process which is difficult to = understand.

but that doesn't really mean one shouldn't offer = it.

frank

------_=_NextPart_001_01C08B5C.53780300--