Instance variables

[Steven <Handerson@CMU-CS-C.ARPA>]

   From: Kahn.pa at XEROX.ARPA
   To:   cl-object-oriented-programming at SU-AI.ARPA
   Re:   Instance variables

   I'm seeing a consensus that we should concentrate first on defining
   hooks into Common Lisp for implementing Flavors, Loops, and the like.

I'm worried about the words "for implementing."  There will probably have to be
more than one substrate used by different object systems, and quite possibly
every major object system will have its own.  Face it, LOOPS and Flavors aren't
that similar.  There is a way we could have portable Flavors (using "symbol
macros"), but I guess Moon thought it was gross.  We won't make it part of the
specs, but interested implementors can still use it to implement the eventual
kernel.  [It doesn't have to be standard to be used.]

Methods are *implemented with* functions.  Specifying the extra arguments is
like specifying an implementation - you could ruin a perfectly wonderful
implementation that way.  Moon has pointed out that Symbolics has had three
implementations of Flavors, and each of them did message passing a different
way.  LOOPS operations ARE functions, but only because there's nothing special
about them; instance variables aren't lexical and you can't compile instance
variables into fast code.  This wins for things that change a lot, but not for
something fairly static like Flavors (which better be fast, or they won't get
used). 

What I was suggesting is that we see what kind of hooks are necessary to allow
objects of all forms to do various useful things in the system.  Some of these
would be analogous to things already accepted, like (print instance stream)
doing a (lisp::send instance 'print stream).  Others might allow objects to
masquerade as other types, such as (CAR instance) doing a (lisp::send instance
'CAR).  As I've said before, if we standardize (1) the functionality of this
lisp::send (meaning what messages and message arguments it gets used with), (2)
the way we tell objects from different systems apart, and (3) the way that
object systems provide translations of these messages into their own sends,
then that takes care of system hooks.