Re: intro material

["Nicolas_Graube.EuroPARC"@Xerox.COM]

Some comments about the ``intro material''.

Section: Metaobjects.

 The limitation on metaobject basic classes seems that these are abstract
classes (limitation expressed by ``Any metaobject must be an instance of a
subclass of ...'').This becomes clear inside the section ``Inheritance
Structure of Metaobject Classes''. Cannot you use the term abstract classes
in order to qualify them directly at the beginning?

SubSection: Classes.

Is it possible to give a clear explanation of the term ``structure''. Is it
only concerned with the number of slot? Nothing is said about the role of
the class of the class. Furthermore the term class metaobject is very
misleading as one can interpreted it as the metaclass...

SubSection:  Slot Definitions.

I do not know if the following paragraph of the Subsection on Slot
Definition is necessary as the information was already provided in the
previous section:

	Associated with each class metaobject is a list of direct slot
	definition metaobjects representing the slots defined directly in the
	class.  Also associated with each class metaobject is a list of
	effective slot definition metaobjects representing the set of slots
	accessible in instances of that class.

SubSection: Methods.

  Omitting information about generic function in the first sentence is a
little bit confusing at first, can you add something like, ``and a
reference to a generic function if any'' to the sentence:

	A method metaobject contains a list of qualifiers, a lambda list, a list
	of specializers, a function and a documentation string.

SubSection: Method Combinations.

 	 \item{\bull} The name of the method combination type is available as a
	symbol.  This name may or may not be the same as the name of the class
	of the method combination metaobject.

It seems that Method Combinations classes are viewed as classes with only
one instance, which will be reinforce by the merging of the name associated
to the method-combination (an instance) and the name of the class depicting
this combination.

Section: Inheritance Structure of Metaobject Classes.

	The class of every class shown is {\bf standard-class} except for the
	class {\bf t} which is an instance of the class {\bf built-in-class} and
	the classes {\bf generic-function} and {\bf standard-generic-function}
	which are instances of the class {\bf funcallable-standard-class}.

Why {\bf Class} is not the root of the instantiation graph? It seems like
this class is more primitive than {\bf Standard-class}. Considering {\bf
Class} as the instantiation's root enables the consideration of a small
kernel on top of which CLOS can be derived (supporting the idea that CLOS
is only a possible paradigm inside the Common-Lisp Object System, and thus
enabling the derivation of some other by inheriting from this kernel).

The adjonction of the sentence   "and for that set of arguments M2 is more
specific than M1;" makes things clearer on the ``shadow'' and ``override''.

Finally I do agree on Moon's comment about the unecessity of two
slot-definition classes for Structure, one seems sufficient.

 Nicolas