Issues in object oriented programming in Common Lisp

[Kahn.pa@XEROX.ARPA]

To different people object oriented programming in Common Lisp means
very different things.  I think the first thing we should do is discuss
what people want done.  I assume most people feel the tension between
some kind of standard (that will help portability, provide an
opportunity to clean up and rationalize existing systems, promote
communication of ideas, etc.) and the dangers of premature
standardization.   

Some of the questions going through my head are:
(1) Is there some small kernel for objects that is adequate for building
multiple inheritance, method specialization, method demons, and whatever
else that people want?
(2) Where do most people stand on some the rather basic issues of
object-oriented systems such as
  (a) Should there be a distinction between classes and instances?  I.e.
should one be able to add methods to instances?
  (b) How private should instance variables be?  Need one send messages
to access them?  To access other's instance variables?  What should be
encouraged vs. enforced?
  (c) Should message passing be based upon selectors or more general
pattern matching?
  (d) Should there be class variables?
  (e) What is a reasonable set of initial classes or flavors?  What
methods should they have?
  (f)  How should "self" be treated?
  (g) How should multiple inheritence work?
  (h) Should there be meta classes?  
  (i) How should objects interface with Lisp?  What should happen if a
Lisp primitive is applied to an object?  Should SETF etc. work on
message sending?  Should objects be functional objects ala ZetaLisp?
  (j) Are methods themselves objects?  Are classes? ...
  (k) Should the system support the notion of protocols that are
collections of behaviors?
(3) Terminology.  Maybe before doing much else we should come to some
consensus about what terminology to use.  Do people think that "flavor"
is better than "class"?   Do people like "subflavor", "abstract flavor",
etc. ?   There seems to be at least three different ways of talking
about objects the Flavors way, the SmallTalk/Loops way, and Hewitt's
actors.  What do people prefer?
(4) Syntax.  What should a method definition look like?  What about a
message transmission?  A flavor definition?

I'm sure that there are a lot more issues that I'm just not thinking
of.   So feel free to add your own.


Instead of 40 people trying to discuss 20 issues simoultaneously, I
propose that we serialize the discussion.  To get things rolling I'll
pick one of the issues above, describe the alternatives, and try to
bring out the arguments pro and con.

(2) (b) Instance variables.
There are several ways in which instance variables are treated in
different object-oriented programming languages.  Flavors takes the
position that the instance variables of "self" can be accessed and set
just as ordinary Lisp variables within a method.  Instance variables of
others are accessed or set via message passing.  To make this easier the
appropriate methods can be generated automatically.  In a language I did
several years ago called Director all instance variable access and
update were done by message sending.   In Loops one refers to instance
variables by function call.  There are macros so that this is as consise
as possible. Lets call these instance variable schemes "Lisp variables
for self", "message passing", and "function call".

Lisp variables for self:  Consise  and potentially very efficient when
refering to self's instance variables; clean, modular,  relatively
inefficient  and verbose when refering to others, nearly impossible to
implement  in Lisp (one must change the kernel to treat specially
variables that it recognizes are instance variables)

Message passing: Very modular, verbose, difficult to optimize, easy to
implement active values (demons on variable access and update) by method
demons or specialization, different name space for Lisp variables and
instance variables.

Function call:  Easy to abuse (e.g. depend upon the internal
representation of other objects), easy to implement active values
(though via a seperate mechanism from method demons), different name
space for Lisp variables and instance variables.

One can make arguments about the arguments:  A different name space is
good because it makes visually clear what is Lisp and what is object.
Modularity is important to maintain the ideal that an object is defined
behaviourally and its internal representation is hidden to the world.
Active values are very useful.  One needs less mechanism if active
values can be supported by method specialization (demons). Etc. 

Don't vote on these issues, instead add your own arguments.

I know that various groups have a lot invested in existing
object-oriented systems in Lisp (Flavors, Loops, KEE, ...).  Perhaps its
too late to re-think some of these fundamental issues.  I see several
possible outcomes from this Common Lisp subgroup's discussions.  Perhaps
a new language will be designed, perhaps some common ground will be
identified, perhaps some existing sublanguage will be accepted by the
community as a standard, perhaps we'll come to understand the issues
better, perhaps nothing will happen.  Its up to us, so please
participate.
Send in your 2 cents worth.