[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Meeting Next Week
Date: 11 Dec 87 13:12 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
My reaction to the supplied chapter 3 is mixed. Let me outline it
As usual, I have only included the parts of your message I am actually
(actually Danny and I both wrote this, but the current state of text
editors is such that I can't say "M-X Pluralize Author")
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.
I think this is a good point. Certainly we could leave specific
implementations free to modularize standard class any way they want.
Also, there is no doubt that we are all uncomfortable with the
common-base design. As I have said before, the question is not "is
there something better" the question is "do we have enough experience to
come up with something better, or is that going to take a few years".
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.
Its true that chapter 3 doesn't give a very good overview. I think we
can do better than what is there. We haven't addressed that issue too
much since because we had PCL out there to do that job for us.
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
That is just symbol-class.
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.
I believe the distinction between classes and names is quite well drawn.
The reason add-named-class has such a complex behavior is because it
must implement the semantics of:
<update it as described in chapter 1>
<define a new one as described in chapter 1>)
The layer underneath the named layer deals with the class and generic
function objects anonymously. Except for the generic functions for
which it is explicitly stated that they deal with names, they all deal
with anonymous objects. Anything that can be done with a named object
can be done with an anonymous object, including the find and update
protocol which defclass provides for named objects.
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 (defethod 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?
Right. I think we have all known for some time that sometimes 'dummy'
arguments are passed to methods to make the method lookup work. Thats
why we added the feature to defmethod to make specialized arguments be
'referred to'. We could consider adding this new kind of specializer
now, but I think its a little late in the game for that. Prototype
instances, even though a little ugly, are simple and work.
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.
Well, we have a fair amount of empirical evidence that suggests that
this protocol can be used to make systems that are fairly different than
CLOS. I think we got a pretty clear inidication of that at the OOPSLA
workshop. There is also a fair amount of other work we have seen that
reinforces this. That work has had a significant influence on this
design, we believe the design outlined in chapter 3 is much better than
the design currently implemented in PCL.
Of course there is the question of what 'almost exactly like CLOS' and
'fairly different than CLOS' mean. Clearly there must be many systems
that no metaobject protocol we could write would provide adequate
8. Of course we need better names for things than names like Collect-slotDs.
But I suspect that DannyB and GregorK won't object.
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
The last paragraph in the introduction to the Instance Structure Protocol
section is an example of this.
I believe that what you are saying is that it should be legal for a
specific implementation to define its own mechanisms for extending the
unerlying type system. I agree. I just don't think we can add to
Common Lisp something that gives users that power since it also gives
them the power to destroy the entire type system.