MOP comments part 1.

[Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>]

I like this draft much better than the first draft that came out last march.


- Section: Class Organization in the CLOS Kernel

I find the argumentation in favor of common base design not very convincing. 

	Secondly, once
	one has understood the features of standard-class one has a complete
	view of the underlying implementation.
This is a feature of the protocol, not the class organization. This is so
because someone can and will turn off or override  some features that are taken
for granted on standard classes. For each generic function, we must describe
what is an intangible behavior and what is left to interpretation by
implementing method.

        Having the mixins is fine if you have cut
	the world exactly right for the variation of class behavior one wants. 
	However, if not, then one has the same type of problem with overriding
	unwanted behavior with multiple mixins
I agree with this. If we think that we can't get it right in a reasonnable
amount of time, then I want to suggest an alternative:

(defclass basic-class ())
(defclass standard-allocation-class (basic-class))
(defclass structure-allocation-class (basic-class))
(defclass standard-class (standard-allocation-class) ...)
(defclass structure-class (structure-allocation-class) ...)
(defclass built-in-class (basic-class))

That's a minimal approach that preserves modularity (no turning off/on methods.)
and conveys the fact that there is only two standard ways to represent
instances. 

- Section: The Classes in the CLOS Kernel

Standard-slot-description should have a slot named "initarg".

- Section: The Named Class Definition Protocol
 
Why would we have to parse the slots at load time instead of compile time?
Add-named-class should be able to accept slot-descriptions as well.

Why would ADD-NAMED-CLASS call CLASS-FOR-REDEFINITION if there is no old class
object. What is the second argument supplied to CLASS-FOR-REDEFINITION in this
case? NIL? 

        The standard-method on add-named-class expects class-for-redefinition to
	return the class to be used for the new definition.
This looks like an intangible property of CLASS-FOR-REDEFINITION as a generic
function.

- Section: The Named Method Definition Protocol

I think a template of what a DEFMETHOD would expand into would be good at this
point. The make-instance protocol for methods and generic function has to be
specified. I guess I need that to understand the following:
        If defmethod is being evaluated at load time (as
	opposed to compile time), the mex object is in fact the method that will
	be returned by the evaluation of the defmethod form.

(defmethod expand-defmethod ((proto-method broadcast-method)
                             name qualifiers lambda-list body environment)
 (call-next-method  name qualifiers 
------------------â?? proto-method should be inserted here.
    (add-key-argument lambda-list '(broadcaster nil broadcast-p))
    `(multiple-value-prog1 (progn ,@body)
        (or broadcast-p
           ,(broadcast-call name lambda-list)))
     environment))

- Section: The Class Update Protocol

	A key property of standard classes is that they can be defined before
	all their superclasses are defined.
True.
	In the processing of the standard method on update-class,
	direct-superclasses argument can contain symbols as well as class
	objects.
I agree.

This Class Update protocol based an eager evaluation model.  I want to propose a
lazy evaluation model.  There is no need to propagate changes downward (to the
subclasses) if the subclasses haven't computed anything from their superclasses.
Computed properties are typically: PCL, effective slot-description, effective
default-initargs...  There is no reason for computing these properties if the
class is not going have instances since a class cannot compute its
effective propeties based on the effective property of its superclasses.

I propose that the lattice structure is updated when FINALIZE-INHERITANCE is
called. PROPAGATE-CLASS-UPDATE will be called only on classes that are
fully-defined.

I also propose to get rid of forward-reference-class. The direct-supers
slot of a class is never mapped to class object. When finalize-inheritance is
called, the mapping is done in order to compute the CPL and other effective
properties but the direct-supers slot is not updated. I thinks it reflects better
what the user expects if the mapping between name and class object changes. 

More next week.
Patrick.