Re: Instance variables

[Kahn.pa@XEROX.ARPA]

I think you left out a 3 somewhere but I see the point.
I like the notion of thinking of a DEFMETHOD as something that expands
to a giant LET binding the instance variables to their values.  The
problem then is with SETQ and the like.
Flavors sort of takes the view that an object is a functional closure
and that DEFMETHOD "edits" the definition of the function.

The reason I brought up active values at the same time as instance
variables is that they depend upon how  instance variables are treated.
A message protocol can capture active values but it requires that
messages always be sent to access and update instance variables even
those of "self".

What I would like (and I think many would) is a message passing
semantics for access and update of instance variables with the
consiseness and efficiency of Flavors.  Perhaps they are not
incompatible (I can imagine a compiler that compiles
(setq foo x) inside a method where foo is an instance variable to
something like (send self ':set-foo x).  But could this be made
efficient?  And is it really desirable to have something that looks like
a setq really be a send?).  Perhaps compromises are necessary.  

I like the idea of private instance variables.  What is a little odd
about them is that they prevent  methods of subflavors from seeing or
changing certain instance variables even though they are instance
variables of the instances of those subflavors.
Or was something else being proposed?