Chapter 3 reading

[Richard P. Gabriel <rpg@lucid.com>]

After a quick reading of the new stuff, here is what I came up
with:

Page 3-3

 In this document, the term {\bit
 metaobject} is used to refer precisely to an object which represent a
 CLOS class, slot definition, generic function, method or method
 combination. 

represent => represents

Page 3-4

 Any metaobject must be an instance of a subclass
 of exactly one of these classes.

That is, there cannot be direct instances of these or such instances are not
metaobjects?

I take it that the term ``available as'' is used to indicate that
these things are observable and when observed have the representations
stated?  Because this construction is odd, you should explain it.

Page 3-5

 Certain kinds of information is associated with both direct and
 effective slot definitions.

kinds ... is => kinds ... are

 Certain other information is only associated with direct slot definition
 metaobjects.

only associated => associated only

Page 3-9 

 \item{\bull} For a given set of arguments, a method $M\sub{2}$ {\bit
 shadows} a method $M\sub{1}$ if and only if $M\sub{1}$ and $M\sub{2}$
 are both associated with the same generic function; and either
 $M\sub{1}$ and $M\sub{2}$ are both primary methods or $M\sub{1}$ and
 $M\sub{2}$ are both {\bf :around} methods or $M\sub{2}$ is an {\bf
 :around} method and $M\sub{1}$ is a primary method; and for that set of
 arguments $M\sub{2}$ is more specific than $M\sub{1}$; and when
 $M\sub{2}$ is invoked, {\bf call-next-method} is called from within its
 body.

First, I think the word `shadow' will fake people out, defined like
this.  Second, I think all :around methods shadow primary methods
regardless of specificity of argument, so you need to word this
differently.

 \item{\bull} For a given set of arguments, a method $M\sub{2}$ {\bit
 overrides} a method $M\sub{1}$ if and only if $M\sub{1}$ and $M\sub{2}$
 are both associated with the same generic function; and either
 $M\sub{1}$ and $M\sub{2}$ are both primary methods or $M\sub{1}$ and
 $M\sub{2}$ are both {\bf :around} methods or $M\sub{2}$ is an {\bf
 :around} method and $M\sub{1}$ is a primary method; and for that set of
 arguments $M\sub{2}$ is more specific than $M\sub{1}$; and when
 $M\sub{2}$ is invoked, {\bf call-next-method} is not called from within
 its body.

:around methods override primary ones regardless of specificity.

 But, this description permits any implementation modifications provided
 provided that for any portable class $C\sub{\hbox{p}}$ that is a
 subclass of one or more specified classes $C\sub{0} \ldots C\sub{i}$,
 the following are true:

provided provided => provided

What is a portable class?

 \item{\bull} The method applicability of any specified generic function
 is the same in terms of behavior as it would had no
 implementation-specific changes been made.

Wow, do you mean to say that the same methods are applicable and do the
same things? This is a sentence the gov'mint coulda written.

Page 3-10
 
 Typically, when a method is allowed to be overridden, a small number
 of related will need to be overridden as well.

related will => related methods will

Page 3-18

 An error is signalled if this value is not a proper list; or if it is
 the empty list; or if {\bf validate-superclass} returns false for any
 element of the list.

The construction ``; or'' is over-punctuated.  Also,
VALIDATE-SUPERCLASS takes two arguments.  I would try this:

 An error is signaled under the following conditions: if this value is
 not a proper list, if it is the empty list, or if {\bf
 validate-superclass} applied the class and any element of this
 list returns false.

This construction occurs elsewhere on this page and the next.

 An error is signalled if this value is not a proper list or; if any
 element of the list is not an instance of the class {\bf
 direct-slot-definition} or one of its subclasses.

 If the class is being initialized, this argument defaults to false.

If it's a proper list, the default must be nil or (), not false.  I
might be wrong about this, but check all uses of nil, false, and empty
list in this subsection.

Page 3-21

 The generic function {\bf map-dependents} can be called to access the
 set of dependents of a class or generic function.  The generic function
 {\bf remove-dependent} can be called to remove an object from the set of
 dependents of a class or generic function.  The effect of calling {\bf
 add-dependent} or {\bf remove-depedent} while a call to {\bf
 map-dependents} is in progress is unspecified.

remove-depedent => remove-dependent

Page 3-22

 ;;;
 ;;; Updaters are used encapsulate any metaobject which needs updating
 ;;; when a given class or generic function is modified. RECORD-UPDATER
 ;;; is called to both create an updater and add it to the dependents of
 ;;; the class or generic functions.  Methods on the generic function
 ;;; UPDATE-DEPENDENT, specialized to the specific class of updater do
 ;;; the appropriate update work.
 ;;;

used encapsulate => used to encapsulate

(defun record-updater (class dependee dependent &rest initargs)
  (let ((updater (apply #'make-instance class :dependee dependee
                                              :dependent dependent
                                              initargs)))
    (add-dependent dependee updater)
    updater))

Why isn't this a generic function or doesn't it use check-type to make
sure CLASS is an updater?

Page 3-24

Why isn't add-direct-method just part of some dependent protocol between
classes and methods, instead of this more direct treatment, or is this
typical of how dependent protocols are handled?

Page 3-28

 The generic function {\bf add-method} adds a method to the set of
 methods associated with a generic function.  After adding the method to
 this set, {\bf compute-discriminating-function} is called and its result
 is installed by calling {\bf set-funcallable-instance-function}.  The
 {\it generic-function} argument is destructively modified and returned
 as the the result.

the the => the

Page 3-29

 Chapter 1 section --- ``Agreement on Parameter Specializers and
 Qualifiers''

section -- ``Agreement => section---``Agreement

This same problem occurs elsewhere.

Page 3-30

 \Defmeth {allocate-instance}
 {({\it class\/} structure-class) {\rest} {\it initargs}}

 The instance returned by this method has slots with undefined values.

I would very much prefer to leave out structures as much as possible
from this protocol. Structures are very nice as they are, and I fear
the possible slowdown of structures or incorrectness and complexity of
implementation in order to accomodate the MOP. The complexity of
implementation is not justified for the simple facility.

Page 3-32

 This method can be overridden.  Because of the consistency requirements
 between this generic function and {\bf
 compute-applicable-methods-using-classes}, doing so may require also
 overidding
 \method{compute-applicable-methods-using-classes}{standard-generic-function
 t}.

This phrasing is better than similar phrasings you have used for this
situation. Replace the others with something like this.

Page 3-35

Under compute-class-precedence-list

 If the specified class or any of its superclasses is a forward
 referenced class an error is signalled.

There are two situations - when the user calls this and when it is
called by the system (at finalize-inheritance time?). In the first
case it should not signal an error, and in the second it should.

Page 3-36

Under compute-discriminating-function

 \label Values:

 The value returned by this generic function is a function.

and later on

 The result of {\bf compute-discriminating-function}
 cannot be called directly with {\bf apply} or {\bf funcall}. 

This means it isn't a function. If you cannot add to X nor subtract
from it, it ain't a number, and if you cannot funcall or apply X, it
ain't a function.

Actually, I think it should not be a function at all, but an instance
of a class that one could call DISCRIMINATOR (with the usual
STANDARD-DISCRIMINATOR). This object is a thing such that when you
SET-FUNCALLABLE-INSTANCE-FUNCTION on a generic function and it, a
funcallable generic function is produced. I suppose this situation
indicates some kind of initialization or reinitialization.

Imagine this implementation: a generic function has a code sequence at
its head which uses a table to determine applicability. The result of
a call to compute-discriminating-function, then, produces some kind of
table object, which is then combined with the code sequence to produce
the funcallableness of the generic function.

Okay, so that shows that this shouldn't be a function, and that there
should be a discrimninator class. But the standard- version of this
part of the protocol could use the rest of the protocol that you
suggest (compute-applicable-methods etc) when subclasses of
discriminators are made and user methods applied, though I feel a
little uncomfortable about it. I prefer making this a whole lot more
abstract, possibly not going this deep in the protocol.

I will think about this more.

 Determination of the the effective method is done by calling {\bf
 compute-effective-method}.

the the => the

Page 3-38

 This generic function returns two values.  The first is an effective
 method.  The second is a list of effective method options.

You should specify ``effective method'' a bit, if even simply to state
that it is some abstract, first class thing.

Page 3-40

 The class of the effective slot definition metaobject is determined by
 calling {\bf effective-slot-definition-class}.  The effective slot
 definition is then created by calling {\bf make-instance}.

Why isn't this just CLASS-OF?

Also, on this page (compute-effective-slot-definition), you
should mention that the list of superclass-slot-definitions are in
CPL order.

I would leave out the structure methods for this.

Page 3-42

 The direct slot definitions are then collected into individual lists,
 one list for each slot name associated with any of the direct slot
 definitions.  The slot names are compared with {\bf eql}.  Each such
 list is then sorted into class precedence list order.  Direct slot
 definitions coming from classes earlier in the class precedence list of
 {\it class} appear before those coming from classes later in the class
 precedence list.

I found this hard to understand because of the phrase ``associated
with any of the direct slot definitions.'' I presume these are the
direct slot definitions for the slot with that name in any of the
classes this class inherits from. It's better to be a little wordy,
but clear.


			-rpg-