State of an object
Last updated at 6:15 pm UTC on 26 May 2018
(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.
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.
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.)