Synder's proposal

[Kahn.pa@Xerox.ARPA]

We've been too quiet lately.  Alan Snyder almost a month ago made
available his "Object-Oriented Programming for Common Lisp" report and
there has been no discussion.  If people are serious about objects in
Common Lisp then we should carefully read and discuss detailed
well-written proposals such as this one.

I'll try to start off a discussion with some of my comments.

The most unique part of  the proposal is the idea that a  method of a
type (aka class or flavor) can directly access only its own instance
variables and methods and must do something special to get inheritance.
This is motivated by "encapsulation" which I understand as making
class/type/flavor definitions more independent of their supers.
This view does not appeal to me because I find myself frequently moving
ivs and methods up and down the hierarchy as I discover that the method
or iv is more or less general than I  originally thought.  I don't think
of subclasses as being so indpendent of their supers.  In some sense the
use of "call-method" and "apply-method" which explictly name the class
where the system should find a method to make subclasses even more
dependent upon the details of the supers.  One must know which class
will be fielding the  equivalent of "send super" while Loops/SmallTalk
discovers that at run time and Flavors discovers that at compile time.
I think  Synder's scheme makes it hard to write a  module which
specialises some classes such that those classes can be independently
re-structured (e.g.  methods moved up or down the hierarchy, or a class
broken up into a few supers/mixins).  

One thing in favor of Synder's system (which he fails to mention) is
that  IV lookups can be compiled very efficiently without the use of
permutation tables as in Flavors.   

I think of Synder's scheme as a system that gives lots of support for
implementing inheritance by sending messages to implicit parts which
correspond to instances of each immediate super.  For example, take his
example of a "child" class with "parent1", "parent2", and "parent3"
supers.  One can rephrase the example in SmallTalk/Loops/Flavor terms as
child having 3 "hidden" ivs initialized as initialized instances of
"parent1", "parent2" and "parent3".   Then certain messages are received
by a "child" which in turn forward the messages to the appropriate
hidden iv.  Is this a reasonable way to view the proposal?

Comments?
  -ken kahn