Re: What is OOP?

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Rosario19 <Ros@invalid.invalid> wrote or quoted:
>

what is oo programming?

>
  Alan Kay coined the term, and, in 2003, I asked him:
>
What does "object-oriented [programming]" mean to you?
>
  . He answered in an e-mail:
>
|OOP to me means only messaging, local retention and protection and
|hiding of state-process, and extreme late-binding of all things.
>
  . My personal interpretation (taking the above source and my
  own observations into account):

I appreciate your efforts in pursuing this and in describing what
you think it all means.  I'm glad to see a discussion about OOP
that goes beyond the common misunderstandings of what is meant.

I would like to respond to your comments with my own understanding
of how Alan views these areas.  I should explain that I have talked
with (and also listened to) Alan enough so that I think I have a
pretty good understanding of what his views are here, but the
comments below are just my impression of his thoughts.

An object is an imaginary building block that contains states
and procedures and can only be accessed from the outside by
sending messages.  The object decides how it reacts (within the
scope of its specification) to a specific message.  (runtime
model)

An object is a blob about which nothing is known except that it is
able to receive messages and act on them (which may include doing
nothing at all).

In object-oriented programming, programs describe under which
conditions which messages are sent to object expressions at
runtime:  For this purpose, there is a dispatch specification
that defines the recipient object expression and the message
to be sent.  This dispatch definition can also be regarded as
an expression whose value is then determined by the recipient
object (as a type of response).  (source code model)

The key property of object-oriented programming is that sending a
message is the only way to accomplish anything.  Sending a
message may start an activity and never return, or it may finish
and return an object value, with the understanding that "object
value" always means using pointer semantics.  There are no data
values as such;  the only kinds of values in OOP are objects.

In addition to sending messages, Smalltalk has ways of using
identifiers to refer to an object, of combining or sequencing
message send constructs, and of assigning an object value (which
again uses pointer semantics) to a named object holder (some form
of identifier), but these capabilities are secondary to the key
property described in the previous paragraph.

It must be possible to determine which object receives a
particular message (late binding) as late as possible (i.e. at
runtime during the evaluation of the dispatch determination):

The late binding that Alan is talking about is the binding of
messages to processing activity.  Note the contrast with calling
a function, where the binding of name to what processing is done
is static rather than deferred.

For this purpose, the recipient object can be specified again
in the dispatch determination itself by means of an expression
that is only evaluated at runtime as late as possible (runtime
polymorphism).

It's true that the returned object value of a sent message can be
used to send a further message, but that is not an occurrence of
binding.  Calling a function through a pointer-to-function relies
on information known only at runtime, but no binding is taking
place for that (except perhaps for the mapping of a variable name
to a location holding the pointer-to-function value).

  Yes, I really think it is better to say that we send messages
  to expressions because which object the expression represents
  is only determined shortly beforehand and can be different
  each time the same code is run several times.

Messages are always sent to objects, not to expressions.

Obviously determining an object value at runtime is useful, but it
isn't any different than determining any other value at runtime.
Calling a function in C that takes two arguments and returns their
sum depends on values determined at runtime, but that nothing to do
with late binding.

The key point is that, having gotten back an object, we can't do
anything with it except send it a message, and the binding of
message to what processing activity will occur always takes place
at the last possible moment.

  But there's something else of equal importance!  It's the
  insight by Uncle Bob (Robert C. Martin) about when procedural
  code is better and when object-oriented code is better.
>
|Procedural code (code using data structures) makes it easy to
|add new functions without changing the existing data
|structures.  OO code, on the other hand, makes it easy to add
|new classes without changing existing functions.
Robert C. Martin
>
|Procedural code makes it hard to add new data structures
|because all the functions must change.  OO code makes it hard
|to add new functions because all the classes must change.
Robert C. Martin

Both of these comments make the mistake of conflating OOP with
programming in languages that have classes.  That isn't what Alan
meant by object-oriented programming.  That Smalltalk has classes
is incidental to what is meant by object-oriented programming;
classes in Smalltalk are simply a way of implementing the abstract
idea of "object-oriented programming" that had started in Alan's
thinking, and actually much earlier than Smalltalk or even Simula.