From:
http://softwareengineering.stackexchange.com/questions/81197/what-did-alan-kay-mean-by-assignment-in-the-early-history-of-smalltalk


(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.)

Best wishes,

Alan Kay

>From me:

I've seen state stored in some really crazy ways, processing done, and
intermediate state stored in ways that were really inefficient.  If the
internal state of objects is sufficiently isolated you could fix all of
that without having to worry that some object somewhere else is relying on
the fact that you created temp storage for processing.  You could change
your internal state and remove the horrible string and parser you developed
without worrying that some other object is also parsing that horrible
string.

It makes much more sense to define what messages an object needs to
process, questions that the Object needs to answer or processing it needs
to do, if you answer all the questions properly and process the data
properly, no other object should care how you arrived at that answer.  An
accessor or mutator is useful if that is part of the external definition or
to help maintain proper processing and state but they should not be added
or used otherwise.

When you have access to an object and you are looking at the instance
variables of the object, it makes more sense to add a method that answers
your questions about that object.  It helps others understand what you are
doing, what state you are examining, how you are using the object.  It
means that if someone needs to remove that instance variable later they can
do that by properly responding to your method using the new method.  One
other benefit of doing things this way is that there may already be a
method that does what you need, and reading through the interface of the
object might stop you from processing the same answer in a different way.
 (something that will come back and bite you later if the answer has new
dependencies but your answer or direct access to ivars doesn't take that
into account).

All the best,

Ron Teitelbaum

On Sun, Mar 26, 2017 at 3:33 PM Bernhard Pieber <pieber at me.com> wrote:

> Am 24.03.2017 um 12:21 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
> >
> > On Fri, 24 Mar 2017, Tobias Pape wrote:
> >
> >>
> >>> On 24.03.2017, at 01:17, tim Rowledge <tim at rowledge.org> wrote:
> >>>> On 23-03-2017, at 3:10 PM, Chris Muller <asqueaker at gmail.com> wrote:
> >>>> I would rather get rid of "create inst var accessors" altogether, then
> >>>> you would not have that problem.   :)
> >>> If I could think of a way of getting away with it I’d make it
> completely impossible to make methods with the same name as an ivar. All it
> does is encourage the sort of scoundrels ( cads! bounders! mountebanks I
> tell you!) that treat classes as Pascal records or C structs.
> Didn’tortabealloweditellya.
> >>
> >> I'd rather have the opposite direction.
> >> All instvars should be required to have accessors; I don't want see any
> code that accesses instvars directly _execpt_ accessors…
> >
> > Why would that be any good?
> > If it is a good idea, then what are instance variables good for?
> I totally agree. This would break encapsulation of all private state.
>
> Cheers,
> Bernhard
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170327/ed97678d/attachment.html>