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 f0TK03709125 for ; Mon, 29 Jan 2001 21:00:03 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f0TK0n723758 . for ; Mon, 29 Jan 2001 21:00:49 +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 f0TK02720925 for ; Mon, 29 Jan 2001 21:00:02 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08A2E.1150A380" Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id VAA18888 for ; Mon, 29 Jan 2001 21:00:02 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f0TK01720920 for ; Mon, 29 Jan 2001 21:00:02 +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 <13.E7859709@mail.listserv.gmd.de>; Mon, 29 Jan 2001 20:59:59 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 484920 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 29 Jan 2001 20:59:59 +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 UAA12397 for ; Mon, 29 Jan 2001 20:59:57 +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 UAA23000 for ; Mon, 29 Jan 2001 20:59:57 +0100 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f0TJxvY25801 for ; Mon, 29 Jan 2001 20:59:57 +0100 (MET) Received: from [195.20.224.209] (helo=mrvdom02.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 14NKSt-0006QR-00 for LATEX-L@urz.uni-heidelberg.de; Mon, 29 Jan 2001 20:59:51 +0100 Received: from manz-3e364861.pool.mediaways.net ([62.54.72.97] helo=istrati.zdv.uni-mainz.de) by mrvdom02.schlund.de with esmtp (Exim 2.12 #2) id 14NKTC-0007sh-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Mon, 29 Jan 2001 21:00:10 +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 UAA23849; Mon, 29 Jan 2001 20:51:29 +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 Date: Mon, 29 Jan 2001 20:51:28 +0100 Message-ID: <14965.51648.871917.414946@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: 3657 This is a multi-part message in MIME format. ------_=_NextPart_001_01C08A2E.1150A380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lars =3D?iso-8859-1?Q?Hellstr=3D81=3DF6m?=3D writes: > OK, you cannot in general assume that the container for one key value = is > assigned before the container for another (this wasn't what I thought = but > it is probably logical if you think about what \DeclareInstance = does). This > fact is probably important enough to be stressed in the documentation = (kind > of "Note to people who write their own templates: You cannot make any > assuptions about the order of assignments carried out by > \DoParameterAssignments."). oh yes (if it is indeed that way), but it would be worth checking if = there is a clear relation of a describable nature and if so that could be = described alternatively. problem really is like this k1 =3Dn \key, l1 =3Dl \key2 then you can't do k1 =3D12pt l1 =3D \key + 10pt in an instance declaration since the \key would not be defined until the instance is used why l1 is evaluted when the instance is created at least i think this is how it behaves currently, maybe that's bad and = one should \def or \edef all keys at declaration time. (ignore for the moment that one shouldn't use \key in the instance since = this is internal to the template body so to speak; one could imagine = something like \keyval{k1} instead if one would go for this kind of feature --- = one problem with \keyval or the whole thing in generls is for which types = should it be allowed and with what semantics? ) frank ------_=_NextPart_001_01C08A2E.1150A380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Templates

Lars =3D?iso-8859-1?Q?Hellstr=3D81=3DF6m?=3D = writes:

 > OK, you cannot in general assume that the = container for one key value is
 > assigned before the container for another = (this wasn't what I thought but
 > it is probably logical if you think about = what \DeclareInstance does). This
 > fact is probably important enough to be = stressed in the documentation (kind
 > of "Note to people who write their = own templates: You cannot make any
 > assuptions about the order of assignments = carried out by
 > \DoParameterAssignments.").

oh yes (if it is indeed that way), but it would be = worth checking if there is
a clear relation of a describable nature and if so = that could be described
alternatively.

problem really is like this

 k1 =3Dn \key,
 l1 =3Dl \key2

then you can't do

 k1 =3D12pt
 l1 =3D \key + 10pt

in an instance declaration since the \key would not be = defined until the
instance is used why l1 is evaluted when the instance = is created

at least i think this is how it behaves currently, = maybe that's bad and one
should \def or \edef all keys at declaration = time.

(ignore for the moment that one shouldn't use \key in = the instance since this
 is internal to the template body so to speak; = one could imagine something
 like \keyval{k1} instead if one would go for = this kind of feature --- one
 problem with \keyval or the whole thing in = generls is for which types should
 it be allowed and with what semantics?  = )

frank

------_=_NextPart_001_01C08A2E.1150A380--