Here is a possible generalization of the templates in the http://www.latex-project.org/talks/tug99.pdf document to classes. The point with the class dogma is that one has data with certain structure that one wants to describe, and that it helps that description (as it lessens programming errors, diminishes the need for repetitive low-level programming, etc). Classes, as used in the C++ paradigm, is a collection of data and functions (also called methods). A derived class D of a class C has the same data and methods as that of C, but one is allowed to add data and new method, and also to override the methods in C by supplying a new definition. There is also the notion of an abstract class, sometimes also called abstract data type (ADT), or interface. This is merely a class which cannot be instantiated. In C++ one creates such an abstract class by indicating that at least one method should not have a definition. The only way to produce runtime code via such a class is to derive a non-abstract class, and then instantiate it. (I skip the C++ polymorphic stuff here, as it seems to have no analog in TeX.) It seems me that the above ideas can be used in TeX. I do not however claim that LaTeX should have it -- I leave it to THEM (the LaTeX gurus) to decide. On page 46 in the document mentioned above, we have the following syntax \DeclareTemplateType{<type>}{<arg-no>} \DeclareTemplate{<type>}{<name>}{<arg-no>}{ <key-name 1>=<key-type 1> <optional-default 1> <storage-bin 1>, <key-name 2>=<key-type 2> <optional-default 2> <storage-bin 2>, ... } { <initial-code> \DoParameterAssignments <action-code> } When translating to classes, it seems me that ``templates'' is the same as a root class (one which is not derived from another class), and the LaTeX ``name'' is a derived class. Then the number arguments an instantiation of a class should have is the sum of the arguments indicated in the class definitions of the class itself and the classes it is derived from. A syntax might look like \new{class}{<name>}{<arg-no>}{ <key-name 1>=<key-type 1> <optional-default 1> <storage-bin 1>, <key-name 2>=<key-type 2> <optional-default 2> <storage-bin 2>, ... } { <initial-code> \DoParameterAssignments <action-code> } \new{derived-class}{<name1>}{<name2>}{<add-arg-no>}{ <key-name 1>=<key-type 1> <optional-default 1> <storage-bin 1>, <key-name 2>=<key-type 2> <optional-default 2> <storage-bin 2>, ... } [ <initial-code> \DoParameterAssignments <action-code> ] The meaning of the optional argument in the ``derived-class'' definition is that if it is present, it overrides the definition of the derived class, otherwise the definition of the class it is derived from is used. The parameter part { <key-name 1>=<key-type 1> <optional-default 1> <storage-bin 1>, <key-name 2>=<key-type 2> <optional-default 2> <storage-bin 2>, ... } is just added to the parameter part of the class it is derived from. The \DoParameterAssignments command just executes them in sequence. One can think of creating abstract classes by merely using a command \AbstractClass command which issues an error in an instantiation unless overridden by a derived class. Then the relation with templates is roughly like this: Instead of \DeclareTemplateType{<type>}{<arg-no>} one might write \new{class}{<name>}{...}{\AbstractClass} This ensures that the class cannot be instantiated, but one can still add parameter in the {...} clause. One variation might be that one writes \new{class}{<name>}{ <key-name 1>=<key-type 1> <optional-default 1> \AbstractClass, ... }{...} but one then will have to figure out how to override this in a derived class. Anyway, we see from [loc cit] that the intended LaTeX template types should have a semantics. For example, on p 43, the list type should set up a list environment. By playing around with these ideas, one might be able to get a list abstract class which is doing that setup in actual code which then needs not be repeated in derived classes. By analyzing such cases, one might thus be able to find a good way to introduce abstract classes in LaTeX. The use of a class derivation and instantiation would then in the case of the ``list'' example above be something like \new{class}{list}{3}{...}{...} % with the \AbstractClass command somewhere \new{derived-class}{enumerate}{0} % 0 here, as no more arguments are used. {...}{...} The instantiations would be somewhat different than LaTeX templates if traditional class dogma should be used. So instead of LaTeX \UseInstance{list}{enumerate} \NoValue \NoValue \BooleanFalse} as on p 45, one would write \use{enumerate} \NoValue \NoValue \BooleanFalse With the ideas of objects I posted here, this is not so difficult to implement, as \new{derived-class}{enumerate} will create an ``enumerate'' object which will have a command named ``enumerate/use''. The latter will in its turn be invoked by the command \use{enumerate}. So here is a difference between LaTeX templates and classes: With classes, once one has made a derivation ``enumerate'' from ``list'', it is a new independent entity which do not any longer carry its origin (that is, ``list'') explicitly with it when called. Instead, if the class it is derived from (or base class) is needed, one should add a variable \BaseClass which every class has. It is easier to see the connection between classes and modules than between LaTeX templates and modules: Suppose we have modules ``TeX'' and ``std'' which both have their internal ``enumerate'' classes. The object names should then be TeX/enumerate std/enumerate The normal way to call these would be to write \use{TeX}{enumerate} \use{std}{enumerate} or perhaps \use{TeX/enumerate} \use{std/enumerate} But suppose we agree on using the ``TeX'' module only, then one might have a command \use{module}{TeX} or perhaps \use{TeX} which redefines \use to expand to \use/TeX, so that \use{enumerate} expands to \use/TeX{enumerate} (but if is unwise to redefine \use, one might use something else, say \Use, instead). Suppose now that one has loaded the TeX module, that it does not have the ``enumerate'' class, and that we want to take that only form std. One way would be to use the long name explicitly \use{std}{enumerate} Because the ``TeX'' and ``std'' modules have different namespaces, there is no problem in loading them both. But if one should shorten this name, then one could have command something like \import{std}{enumerate} and henceforth be able to write \use{enumerate} instead of the long command. Again, it is not so difficult to do that with the object model I presented, because \import{std}{enumerate} needs only to define a command \enumerate/use which expands to \std/enumerate/use (besides from checking if the name ``enumerate/use'' is in use). OK. This was an input. I leave it to THEM and YOU to decide if it is useful for LaTeX in some form or another. Hans Aberg * Email: Hans Aberg <mailto:[log in to unmask]> * Home Page: <http://www.matematik.su.se/~haberg/> * AMS member listing: <http://www.ams.org/cml/>