X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1058" "Tue" "14" "October" "1997" "14:28:57" "+0200" "Hans Aberg" "haberg@MATEMATIK.SU.SE" nil "22" "Re: LaTeX journal and publisher macros" "^Date:" nil nil "10" nil nil nil nil nil] nil) Received: from listserv.gmd.de (listserv.gmd.de [192.88.97.1]) by mail.Uni-Mainz.DE (8.8.5/8.8.5) with ESMTP id OAA01358; Tue, 14 Oct 1997 14:29:20 +0200 (MET DST) Received: from lsv1.listserv.gmd.de by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <7.FF206C40@listserv.gmd.de>; Tue, 14 Oct 1997 14:29:09 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 214888 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 14 Oct 1997 14:28:42 +0200 Received: from mail.nada.kth.se (root@mail.nada.kth.se [130.237.222.92]) by relay.urz.uni-heidelberg.de (8.8.7/8.8.7) with ESMTP id OAA28704 for ; Tue, 14 Oct 1997 14:28:36 +0200 (MET DST) Received: from [130.237.37.124] (sl92.modempool.kth.se [130.237.37.118]) by mail.nada.kth.se (8.8.7/8.8.4) with ESMTP id OAA19615 for ; Tue, 14 Oct 1997 14:28:34 +0200 (MET DST) X-Sender: su95-hab@mail.nada.kth.se References: Your message of "Tue, 14 Oct 1997 10:45:38 BST." <2749-Tue14Oct1997104538+0100-s.rahtz@elsevier.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Reply-To: Mailing list for the LaTeX3 project In-Reply-To: Date: Tue, 14 Oct 1997 14:28:57 +0200 From: Hans Aberg Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: LaTeX journal and publisher macros Status: R X-Status: X-Keywords: X-UID: 2466 At 11:27 +0100 97/10/14, Robin Fairbairns wrote: >Hans Aberg suggested: > >> This can be sorted out by ideas of object orientation: Class A uses local >> names A/foo, and class B uses local names B/foo; thus they do not clash. > >And then shows how such a technique might be used. An interesting >idea, but I can't convince myself that it's the `right' way forward. The correct way to understand if various object oriented techniques and such are the right things, is to make a research prototype and then experiment with that: Such techniques are otherwise difficult to understand. One reason for this, is that it is about supplying structures that are not there before and which formally are not necessary. -- It is widely discussed why OOP is useful; one reason though is that it helps the handshaking between structures. I have not made my stuff public, but I may do that sometime in the future. Hans Aberg * Email: Hans Aberg * AMS member listing: