I have been reading The Early History of Smalltalk and there are a few mentions of "assignment" which make me question my understanding of its meaning:


  Though OOP came from many motivations, two were central. The large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether.


(from 1960-66--Early OOP and other formative ideas of the sixties, Section I)


  What I got from Simula was that you could now replace bindings and assignment with goals. The last thing you wanted any programmer to do is mess with internal state even if presented figuratively. Instead, the objects should be presented as site of higher level behaviors more appropriate for use as dynamic components. 
  (...)
  It is unfortunate that much of what is called "object-oriented programming" today is simply old style programming with fancier constructs. Many programs are loaded with "assignment-style" operations now done by more expensive attached procedures.


(from "Object-oriented" Style, Section IV)

Am I correct in interpreting the intent as being that objects are meant to be façades and any method (or "message") whose purpose is to set an instance variable on an object (i.e. an "assignment") is defeating the purpose?  This interpretation appears to be supported by two later statements in Section IV:


  Four techniques used together--persistent state, polymorphism, instantiation, and methods-as-goals for the object--account for much of the power. None of these require an "object-oriented language" to be employed--ALGOL 68 can almost be turned to this style--and OOPL merely focuses the designer's mind in a particular fruitful direction. However, doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.


...and:


  Assignment statements--even abstract ones--express very low-level goals, and more of them will be needed to get anything done. Generally, we don't want the programmer to be messing around with state, whether simulated or not.


Would it be fair to say that opaque, immutable instances are being encouraged here?  Or is it simply direct state changes that are discouraged?  For example, if I have a BankAccount class, it's OK to have GetBalance, Deposit and Withdraw instance methods/messages; just make sure there isn't a SetBalance instance method/message?

The basic idea (influenced by Sketchpad) is that most variables/values are in dynamic -relationships- with each other (maintained by the interior of the object), so being able to directly reset a value from the outside is dangerous. Because (in Smalltalk anyway) there is at least a setter method required, this allows the possibility of an outside setting action to be mediated by the internal method to maintain the desired interrelationships. But most people who use setters simply use them to simulate direct assignments to interior variables, and this violates the spirit and intent of real OOP.

But objects do have "world lines" of changes in time. This can be thought of as a -history- of versions of the object in which the -relationships- are in accord. There are no race conditions in this scheme ... an object is only visible when it is stable and no longer computing. This is like a two phase clock in HW. (Idea from Strachey, and in a different from by McCarthy, and influenced by Lucid.)

Best wishes,

Alan Kay
