Different systems, variables

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

Ken,

My own impression is that nobody knows how to do object oriented programming
(multiple inheritance in particular) "right," if there is indeed a right way;
instead, there are just a bunch of different ways of dealing with similar
problems.  I would favor working backwards from existing systems- that would
give those of us familiar with only one system a chance to learn about others.
We might be able to come up with some commonalities, but I doubt they would
mean much in and of themselves.

Flavors people want instance variables to look like variables; this pretty much
requires that they act like them with respect to locality.  If the semantics of
a method syntax depend on other than the target Flavor, changing those might
require many methods to be recompiled - painful, and currently impossible for
methods that have closed over something.  Tagging the references with @! or
something lets the system nonambiguously associate references with the
operation, which it can then use in whatever way it wishes.

I'm partial to the "lisp variables for self", since it leads to an efficient
representation.  It was difficult to implement, but not impossible; Symbolics
and I do it two different ways.  I also think active values could be added to
Flavors - it's just a question of working out the specifics of a proposal.  [If
someone familiar with these is interested in working out a proposal, I'd be
willing to put some time into it.]

I believe that one of the whole points of object-oriented programming is that
an object (and no one else) is responsible for its own integrity (behavioural).
Some instance variables might represent individual pieces of state; others
might be related in some complex way.  Those that are related probably want to
be private- not accessible from anything but the class itself.  If Flavors had
a :private-instance-variables option that would disallow inheriting those
instance variables, that would cover it.

-- Steve