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