X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2717" "Tue" "14" "October" "1997" "16:08:03" "+0200" "Hans Aberg" "haberg@MATEMATIK.SU.SE" nil "60" "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 QAA22953; Tue, 14 Oct 1997 16:09:23 +0200 (MET DST) Received: from lsv1.listserv.gmd.de by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <5.DCDC5D2A@listserv.gmd.de>; Tue, 14 Oct 1997 16:08:24 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 214957 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 14 Oct 1997 16:08:15 +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 QAA05510 for ; Tue, 14 Oct 1997 16:08:08 +0200 (MET DST) Received: from [130.237.37.124] (sl62.modempool.kth.se [130.237.37.82]) by mail.nada.kth.se (8.8.7/8.8.4) with ESMTP id QAA28590 for ; Tue, 14 Oct 1997 16:08:02 +0200 (MET DST) X-Sender: su95-hab@mail.nada.kth.se References: Your message of "Tue, 14 Oct 1997 14:28:57 +0200." 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 16:08:03 +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: 2469 At 13:55 +0100 97/10/14, Robin Fairbairns wrote: >Hans Aberg writes: >> 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. > >What I said was, that Hans's proposal was interesting but that I >hadn't concluded that it was the `right way forward'. I meant exactly >what I said: I didn't mean I didn't understand it. ... >There is a >problem with knowing whether it's necessary. I believe it imposes an >extra burden of understanding on the user (and hence of documentation >on the implementor), so I don't want to rush into its use without >being entirely sure that it's the right thing. Here we have the two OOP opposites at once: Even though it is not difficult to understand the logical implementation structure once it is done, it is still difficult to understand how to apply it, and figure out if it is useful. Then, the reason for this is that one is implementing structures from the real world which are not really needed for carrying out the computations, but is a way to organize the programming. >There is no problem in my mind with implementing Hans's suggestion >(though I would be interested to see his implementation). I do not know how to implement true OOP techniques in TeX (in view of those structural problems above). So it is great somebody else knows it. :-) > If we are likely to run out of name space, Hans's proposal >(which I would identify with > > @InCollection{saltzer:names, > author = "Saltzer, J. H.", > title = "Naming and {B}inding of >{O}bjects\nocite{bayer:os-advanced}", > crossref = "bayer:os-advanced", > chapter = "3.A", > pages = "100--208" > } >which is the classic naming paper) comes into its own. It's more than that, because in OOP, one could define "author" as a structure containing several substructures, such as "name". Then the structure "name", if it should be truly international could be highly complex, with substructures such as "given name", "family name", "nick name". When calling those substructures, one would normally not do it directly, but through method calls corresponding to name formats Albert Einstein Einstein, Albert and so on. The advantage is that the team making use of the "author" structure need not knowing the details of what the team designing the "name" structure is doing: So it is an advantage when the code evolves and becomes rich on structure. Hans Aberg * Email: Hans Aberg * AMS member listing: