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?