chapter 3 comments

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

Here are some more assorted questions, comments, and suggestions regarding
the Meta Object Protocol, with reference to draft 10 [document 89-003
dated 12/15/88].


Page 3-9 says the "metaclass of every class shown is STANDARD-CLASS ..."
-- shouldn't STRUCTURE-OBJECT be of metaclass BUILT-IN-CLASS or
STRUCTURE-CLASS ?

p. 3-16 - why is the doc string a separate argument to making a method
instead of being included in the function lambda expression?

p 3-19,20 in canonicalized initial-method, can't the :QUALIFIERS entry be
omitted when the value is NIL?

Function STANDARD-INSTANCE-ACCESS appears to have been redefined
incompatibly from the March 1988 draft.  Isn't some primitive function
still needed for access by name?

Regarding ADD-DIRECT-METHOD and SPECIALIZER-DIRECT-METHODS; do we really
have to do that when the specializer is class T?  That seems like it
would be just a waste of space.

I wonder about the methods on ADD-DIRECT-METHOD, REMOVE-DIRECT-METHOD,
SPECIALIZER-DIRECT-METHODS, and SPECIALIZER-DIRECT-GENERIC-FUNCTIONS for
class T; since they apparently exist only to support use of (EQL object)
specializers, wouldn't it be better for those methods to specialize on
class CONS ?

P. 3-36 - APPLY-METHOD-FUNCTION "is called whenever a method function must be
applied to arguments."  -- it surely must be permissible for an implementation
to bypass this for the sake of efficiency.  [Otherwise, how would you invoke
the methods for APPLY-METHOD-FUNCTION ?]

The reason isn't apparent for wanting to separate
UPDATE-DISCRIMINATING-FUNCTION from COMPUTE-DISCRIMINATING-FUNCTION; it seems
like the question of whether the function needs to be recomputed would be
inseparably connected to the nature of the code generated.

How come MAKE-METHOD-LAMBDA returns a lambda expression but
COMPUTE-DISCRIMINATING-FUNCTION returns a function?  Is the assumption
that the code for a generic function will always be computed at run time
rather than compile time?  This isn't true since GENERIC-FLET and
GENERIC-LABELS can often be optimized to fully build the generic
function at compile time when it can be seen that the methods are not
changing at run time.  It seems like COMPUTE-DISCRIMINATING-FUNCTION
should instead return a lambda expression and be called something like
COMPUTE-DISCRIMINATING-LAMBDA.

p. 3.43 - How is COMPUTE-EFFECTIVE-METHOD going to know what value to store
for METHOD-SPECIALIZERS ?  Looks like that needs to be an additional argument.

p. 3-58 EXTRACT-LAMBDA-LIST and p. 3-59 EXTRACT-SPECIALIZER-NAMES - "If the
specialized-lambda-list argument does not have legal syntax, an error is
signalled." -- it isn't clear what amount of error checking is required here.
Is it just expected to report an error if it happens to come across one while
stripping out the specializers, or is it supposed to scan all of the optional
arguments for valid syntax according to page 60 of CLtL?

p. 3-61 FIND-METHOD-COMBINATION - I don't understand this.
DEFINE-METHOD-COMBINATION returns a method combination object which was
created without reference to any particular generic function or argument
values.  Does FIND-METHOD-COMBINATION return something different from that,
or why does it depend on the generic function?

Pages 3-62 and 3-65 specify :AFTER methods on REINITIALIZE-INSTANCE for
classes CLASS and GENERIC-FUNCTION that don't do anything but call
MAP-DEPENDENTS.  Couldn't both cases be handled by a single method on class
DEPENDEE-MIXIN ?

p. 3-62 SHARED-INITIALIZE method - "If class has not previously been
initialized ..." -- How does it determine that?  The March draft had a
CLASS-INITIALIZED-P function which doesn't seem to be here anymore.
Shouldn't any behavior that depends on whether the object is previously
initialized be handled by separate methods for INITIALIZE-INSTANCE and
REINITIALIZE-INSTANCE ?  Also, it seems a little odd to specify using an
:AFTER method on SHARED-INITIALIZE when the primary method won't have
anything to do.  Likewise for GENERIC-FUNCTIONs on page 3-65.

p. 3-66, 3rd bullet: "The :DECLARATIONS argument is a list of declarations.
An error is signalled otherwise." -- The SHARED-INITIALIZE method could make
sure this is a list, but wouldn't it be better to let
COMPUTE-DISCRIMINATING-FUNCTION decide whether the declarations are
meaningful?  A portable SHARED-INITIALIZE method doesn't have any way to know
what declarations the implementation will permit.

p. 3-68 -- since REINITIALIZE-INSTANCE is not permitted for methods, wouldn't
it be simpler to initialize them with an INITIALIZE-INSTANCE method instead
of using SHARED-INITIALIZE?  Likewise for slots on page 3-71.

p. 3-75, the arguments shown for generic function MAKE-METHOD-LAMBDA and its
primary method are not consistent.  One shows <lambda-expression> and the
other shows <lambda-list> and <body>.  Which is right?

p. 3-80, shouldn't the blank space at the bottom of the page contain something
to the effect that the next three functions [CLASS-PRECEDENCE-LIST,
CLASS-PROTOTYPE, and CLASS-SLOTS] signal an error if the class is not
finalized?  Shouldn't that also apply to CLASS-DEFAULT-INITARGS [currently on
page 3-79]?

P. 3-83 specifies a CLASS-PROTOTYPE method for BUILT-IN-CLASS -- is that
really useful?  Is it even meaningful?  Sure, a meaningful prototype could be
returned for a representation class such as FIXNUM or SYMBOL, but what would
be a meaningful prototype for an abstract class such as NUMBER, SEQUENCE,
STREAM, or FUNCTION ?  What should (CLASS-PROTOTYPE (FIND-CLASS 'T)) return?

p. 3-83 says that CLASS-PROTOTYPE returns a value which is maintained by
FINALIZE-INHERITANCE.  The March draft said that the prototype instance did
not have to be allocated until the first time CLASS-PROTOTYPE is called,
which seems like the way it should be.  It is not uncommon to define a class
which will only have one large instance and for which the prototype will
never be needed.  Or maybe page 83 just means that FINALIZE-INHERITANCE
ensures that CLASS-PROTOTYPE won't return an obsolete value?

Regarding SLOT-DEFINITION-INITFORM, since it appears that it would only
be used for debugging or informational purposes, I wonder if it shouldn't
have the same implementation freedom as in proposal FUNCTION-DEFINITION
to not always have to save the source form.

p. 3-117 VALIDATE-SUPERCLASS, reference to whether "the superclass has no
slots" -- does this mean forcing the superclass to be finalized, or is a
traversal of its supers intended?

It seems a little odd that the March draft had a function named
VALID-SUPERCLASS-P which signalled an error, while this draft has a predicate
named VALIDATE-SUPERCLASS; seems like those names are interchanged.

p. 3-35, 3-107 methods for BUILT-IN-CLASS -- "this method signals an
error" - is it permissible for that method to simply not be defined,
resulting in a "no applicable method" error, or does that method actually
have to be defined in a conforming implementation?  Perhaps the real point
is that users should not be permitted to define those methods?

Is the concept of initial methods useful for local generic functions?  The
only use of GENERIC-FUNCTION-INITIAL-METHODS appears to be for
redefinition of named generic functions, which is not applicable to the
anonymous generic functions created by the forms GENERIC-FUNCTION,
GENERIC-FLET, and GENERIC-LABELS.