X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2257" "Tue" "7" "December" "1999" "23:56:14" "+0100" "Hans Aberg" "haberg@MATEMATIK.SU.SE" nil "51" "Re: Classes -- a generalization of templates" "^Date:" nil nil "12" nil "Classes -- a generalization of templates" nil nil nil] nil) Return-Path: Received: via tmail-4.1(11) (invoked by user schoepf) for schoepf; Wed, 8 Dec 1999 00:03:51 +0100 (MET) Received: from mail.Uni-Mainz.DE (trudi.zdv.Uni-Mainz.DE [134.93.8.159]) by mailserver1.zdv.Uni-Mainz.DE (8.9.1b+Sun/8.9.1) with ESMTP id AAA04184 for ; Wed, 8 Dec 1999 00:03:51 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id AAA19589 for ; Wed, 8 Dec 1999 00:03:48 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <6.2735A2A5@mail.listserv.gmd.de>; Wed, 8 Dec 1999 0:03:43 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 445208 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Wed, 8 Dec 1999 00:00:50 +0100 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id AAA23521 for ; Wed, 8 Dec 1999 00:00:48 +0100 (MET) Received: from musse.tninet.se (musse.tninet.se [195.100.94.12]) by relay.uni-heidelberg.de (8.9.1b+Sun/8.9.1) with SMTP id AAA21535 for ; Wed, 8 Dec 1999 00:01:26 +0100 (MET) Received: (qmail 24102 invoked from network); 8 Dec 1999 00:01:24 +0100 Received: from du130-226.ppp.su-anst.tninet.se (HELO ?195.100.226.162?) (195.100.226.130) by musse.tninet.se with SMTP; 8 Dec 1999 00:01:24 +0100 X-Sender: haberg@pop.matematik.su.se References: <417f4014@corona.oche.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Reply-To: Mailing list for the LaTeX3 project In-Reply-To: <14413.33805.485658.811893@Wincenty.nowhere.edu.pl> Date: Tue, 7 Dec 1999 23:56:14 +0100 From: Hans Aberg Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: Classes -- a generalization of templates Status: R X-Status: X-Keywords: X-UID: 3449 At 23:02 +0100 1999/12/07, Marcin Wolinski wrote: >> I think I pointed that the dynamic aspect does not appear to make sense in >> TeX. Therefore I concentrated on the static, namespace, aspect, which just >> as templates just requires macro expansions. > >The problem is you cannot fully implement static namespaces in TeX --- >not for all primitive datatypes present. With much of the development of computer languages, there is the idea that the user should be forced to program in certain ways. TeX does not have such a mechanism that could put restraints of usage in say LaTeX. It would be great if TeX had such a capacity, but there is no point in taking up that aspect with TeX as it now is. >So the seemingly obvious similarity to objects is in fact rather >misleading. I should said that what I called an ``object'' in my TeX description is not say a C++ class or anything similar. Another comment though is that even though that the final TeX output is a static DVI page, the processes at arriving there are fairly dynamic: One can after all use \def to define a new operator. The difference between say \newenvironment and \new{environment} is that the latter can be used ``dynamically'' with a parameter \new #1 The fact that the use of \csname..\endcsname makes this slow is then just a variation of a general fact that programming with dynamic structures is slow. One can even do something that is similar to polymorphism in TeX by the use of the \let operator: \let\a\b ``mutates'' the \a macro into the value of the \b macro. I just mention this as an input of ideas: If one has the ideas of OOP in ones mind, then one might make use of this in LaTeX somehow. I think that LaTeX will require OOP at least in the form of localization of macro names into different namespaces, due to the fact that LaTeX has grown so wast, and this will be needed in order to avoid name clashes, and so that one program against interfaces without really having to know about the interior of the objects one is manipulating. Hans Aberg * Email: Hans Aberg * Home Page: * AMS member listing: