[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?