Re: What is OOP?

On Thu, 2025-03-27 at 18:23 +0000, Mr Flibble wrote:

On Mon, 17 Mar 2025 10:17:51 -0700, Tim Rentsch wrote:
 

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.

 
Wrong. OOP is:
 
* Encapsulation
* Inheritance
* Polymorphism (including LSP)
* Abstractions
 
The above necessitates the need for classes or similar.
 
/Flibble

Blind reciting! Or, useless (worse than none, garbage definition).