Comments on MOP

[Dick Gabriel <RPG@SAIL.Stanford.EDU>]

The following is a part of a message to a subset of the readers of
this list (which contained other comments) concerning my reaction to
the proposed chapter 3.

My reaction to the supplied chapter 3 is mixed. Let me outline it briefly:

1. I am uncomfortable with the common-base (or subtractive) philosophy. I
believe it to be a priori incorrect though practical. I would submit for
consideration a modification, which is that the meta-object protocol be in
terms of the large classes (standard-class and friends) but that the
ontology of those classes be unspecified. That is, I think we can leave
open the question as to whether standard-class is a diamond or an
accumulation of mixins - making that an implementation choice - and also
leave open whether extensions to the protocol based on mixins from
constituent classes is possible.

As important as what is said in a specification is what is unsaid.

2. Although the meta-object protocol is advertised as an interpreter - which
seems to be a good presentation mechanism at least - there is no explicit
picture of what that interpreter is like. Possible situations would be
an informal description, a set of constraints, or an actual piece of
pseudo-code. Without such an overview, it is very difficult to get the
big picture from chapter 3.

One might argue that PCL fills that gap for now, but I don't believe we
should rely on a difficult-to-read piece of code to understand the
details of a proposal.

3. I fear that too much hidden detail exists. For example, there is a casual
mention of a ``class name table'' in the description of ADD-NAMED-CLASS. This
term is nowhere mentioned, and it is not clear whether this is a thing that
must exist in every CLOS or whether this is a device in the possibly
fictitious interpreter.

4. There is too little orthogonality between objects and names.
ADD-NAMED-CLASS would seem to require a name and a class as arguments, yet
it takes a prototype instance, a name, and a bunch of stuff for making up
a class. I would have guessed that ADD-NAMED-CLASS is a combination of
UPDATE-CLASS and something else. The fact that it might be necessary to
package name and object handling into one place strikes me as a hint
of tangled design.

Since it appears that this is intended to model the semantics of
DEFCLASS when re-defining a class, perhaps it's better for the
expansion of DEFCLASS to be

	...(if <class-with-this-name-exists-p>
	       <update the definition>
	       <create a class and install it>)

rather than having a function that embodies this code.

I suppose I never got over the dislike I had for the decision to
require DEFCLASS to preserve EQness upon redefinition.  I suppose the
decision is still a reasonable one because it is too much work to
consider a change in the class hierarchy to be a change to some of the
generic functions defined on it, thereby invoking the generic-function-changed
protocol.

5. The existence of prototype instances all over gives me the feeling that
the descriptive mechanism for methods is poor. It appears that these
prototypes mostly solve the problem of arranging for a method on some
superclass to be selectable where (defmethod f ((class (eql C1))...) would
not work.  Since we have dirtied the language with EQL already, how about
(defmethod foo ((class (at-most C1)))...) which means that CLASS must be
a class that is either C1 or a subclass of C1?

6. I didn't see a clear set of mechanisms for optimizing anonymous classes
along the lines of the example piece of code in the section on
CLASS-FOR-REDEFINITION. Are anonymous objects too faceless in this
specification?

7. My impression is that the proposed protocols are good for making
OOP systems that are almost exactly like CLOS but bad for anything
different. The subtractive philosophy advertises that.

8. Of course we need better names for things than names like Collect-slotDs.
But I suspect that DannyB and GregorK won't object.

9. The section on Instance Structure Protocol seems too wedded to
a structure-like representation. Depending on how specific the
interpreter presentation will be, it might make sense to be a little
more abstract about the nature of the mappings from slots to representation.

10. Too much emphasis has gone into making portable implementations of
CLOS possible. Because there is no portable way to extend the Common Lisp
type system doesn't mean that we must outlaw things that could be done in
a Common Lisp in which that is possible. There must be a careful
distinction made between the mistakenly requiring as portable things that
are non-portable on one hand, and foolishly prohibiting things that are
not portable.

The last paragraph in the introduction to the Instance Structure Protocol
section is an example of this.

11. The generic-function-changed protocol does not specify the definition
of a generic function change - when is this protocol triggered?

			-rpg-