editorial comments on chapter 3

[David N Gray <Gray@DSG.csc.ti.com>]

Following are some questions, comments, and suggestions about Meta Object
Protocol draft 10 [document 89-003 dated 12/15/88].  This message is limited to
comments on the document itself; questions about the protocol design will be
raised in separate messages to follow.


page 3-9 -- class METAOBJECT is shown as a subclass of FUNCTION; that must
be a mistake since it would imply that class objects and slot definitions
are funcallable.

p. 3-16 and 3-17 - don't the calls to ENSURE-GENERIC-FUNCTION require a
:LAMBDA-LIST argument?

Generic function EFFECTIVE-SLOT-DEFINITION-CLASS is mentioned on pages
3-24, 3-45, and 3-47, but it is not included in the individual function
specifications.

On page 3-24, it appears that "class finalization protocol" and "instance
structure protocol" ought to be section headings.

Bottom of page 3-25 "location must be a positive integer" -- does that
mean not negative or greater than zero?

Page 3-26 mentions functions STANDARD-INSTANCE-ACCESS,
FUNCALLABLE-STANDARD-INSTANCE-ACCESS, and STRUCTURE-INSTANCE-ACCESS,
which are not detailed later.

p. 3-26, SET-FUNCALLABLE-INSTANCE --> SET-FUNCALLABLE-INSTANCE-FUNCTION

p. 3-27 -- FUNCALLABLE-STANDARD-CLASS is mentioned in several places, but
there is still no definition of just what it is.

p. 3-33 - Shouldn't ADD-METHOD be specified to alter the method object by
storing the value to be returned by METHOD-GENERIC-FUNCTION?  I assume
that "if the method object is a method object of another generic function
..." means to check the value returned by METHOD-GENERIC-FUNCTION before
storing the new value?

p. 3-33 not clear what "... readers of the method object are expected to
be invariant ..." means; is this talking about the definition of the
accessor methods or the values that they access?  Or both?

p. 3-35 - Description of ALLOCATE-INSTANCE should mention that it is
called by MAKE-INSTANCE.  (not shown on graph either; the only place this
appears is page 1-41.)

p. 3-41 mentions function UPDATE-DISCRIMINATING-FUNCTION in the "purpose"
section and UPDATE-DISCRIMINATOR-CODE in the "remarks" section; neither of
these is included in the function specifications.  The graph shows
UPDATE-DISCRIMINATING-FUNCTION.  Page 3-67 says that
"UPDATE-DISMCRINATING-FUNCTION" [sic] is called by the SHARED-INITIALIZE
method, but that call isn't shown on the graph.

p. 3-43 COMPUTE-EFFECTIVE-METHOD - doesn't specify the value returned;
presumably a method object.  Is it a STANDARD-METHOD or should there be a
subclass for effective methods?

p. 3-45, 2nd line from bottom, "options is follows" -> "options follows"

p 3-46, the top six lines are a duplicate of material on the previous
page.

p 3-47, COMPUTE-SLOTS -- it isn't clear where the result of this is.  Does
it return a list of effective slots, or does it store the list in the
class object?

p. 3-60 mentions function SLOT-ACCESSES-TO-DEOPTIMIZE which isn't defined
elsewhere.

p. 3-62 "No method applicable to class objects is specified for the
INITIALIZE-INSTANCE generic function."  -- Don't you mean no method more
specific than the one for STANDARD-OBJECT specified on page 2-57?  Surely
that method is applicable.  Likewise on pages 3-65, 3-68, and 3-71.

p. 3-63, fourth bullet, reference to "REMOVE-DIRECT-SUPERCLASS" should be
"REMOVE-DIRECT-SUBCLASS".

p. 3-69 -- the boxed table has the wrong set of function names [should be
METHOD-QUALIFIERS, etc.] and does not list all of the relevant arguments.

p. 3-70 -- the reference to MAP-DEPENDENTS here appears to be bogus since
page 3-22 says that "method combination objects cannot be redefined" and "the
REINITIALIZE-INSTANCE generic function signals an error ...".

p. 3-72 mentions function SLOT-DEFINITION-DOCUMENTATION, which is not listed
among the slot readers on page 3-90; shouldn't that just be DOCUMENTATION ?

p. 3-75, MAKE-METHOD-LAMBDA, says "The generic function and method the method
function will be used with are not required to be the specified ones."  In
fact, the method can not be the actual one since it can't be created until
after MAKE-METHOD-LAMBDA has been used to construct a value for the :FUNCTION
initarg [p. 3-68].  It would be clearer to say that the second argument of
MAKE-METHOD-LAMBDA is a prototype that is only used for dispatching to the
right method.

p. 3-86 mentions a method for (SETF GENERIC-FUNCTION-NAME), but that isn't
listed with the generic functions on page 3-85.  Is it correct to assume that
this is the only one of these accessors which is SETF-able?

p. 3-88 - Does METHOD-GENERIC-FUNCTION return NIL if no ADD-METHOD has
been done?

p. 3-89 -- A number of details yet to be filled in here, like what does
METHOD-COMBINATION-OPTIONS return -- a P-list, or an A-list, or what?

p. 3-90 says that generic function SLOT-DEFINITION-NAME can return "any
object", but page 3-72 says that initialization of a slot signals an
error if the name "is not a symbol which can be used as a variable
name."  So how can the name get to be anything other than a symbol?

p. 3-91 SLOT-DEFINITION-INITARGS -- I assume this returns a list of
symbols?

p. 3-91, 1st line under "Methods", "functions has a" -> "functions have a"

p. 3-91 under the heading "Direct Slot Definition Objects", there are methods
specified for class SLOT-DEFINITION; that should be DIRECT-SLOT-DEFINITION to
be consistent with page 3-73.  Or should it be
STANDARD-DIRECT-SLOT-DEFINITION ? 

The graph shows that REMOVE-DIRECT-METHOD is called by REMOVE-METHOD,
but neither page 3-94 or page 3-97 says that.

p. 99 needs some more words.

p. 3-102 DIRECT-SLOT-DEFINITION-CLASS -- what is this doing in this
place in the document?  It should either be placed in alphabetical order
between pages 47 and 48, or included with the class accessors starting
on page 79.

p. 3-102 -- I assume that DIRECT-SLOT-DEFINITION-CLASS is supposed to
have a specified method for class STANDARD-CLASS that returns class
STANDARD-DIRECT-SLOT-DEFINITION ?

p. 3-109 is unfinished.

The spec doesn't say who calls FINALIZE-INHERITANCE, although the graph shows
it called by ALLOCATE-INSTANCE.  (I'm talking here about finalizing the class
being allocated, not the special cases described in class initialization.)
Presumably ALLOCATE-INSTANCE also calls CLASS-FINALIZED-P, although that is
not shown on the graph.

The organization of this document in a semi-alphabetical order is rather
awkward.  I think it would be better to have the material grouped by subject
and add an index.