Re: What is OOP?

On Mon, 2025-03-17 at 10:17 -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.

Agreed.
From the view of Spu (revised Turing Machine model), 'OOP' is the result of
ctor/dtor, associated with it is the instruction being called as 'access method'.
-------
Wy.Sct.Spu(3wy)                                                 Wy.Sct.Spu(3wy)

NAME
       Spu - Class of general purpose Soft-CPU

SYNOPSIS
       Except POD types, C structures, all types are declared in namespace Wy.

       #include <CSCall/Sct.h>

       Spu  (Soft  CPU)  is  a revised model of Turing Machine and a class that
       acts like a general purpose CPU-based computing machine to  provide  se‐
       mantics for computing language and for remote program communication.

       The  main differences of Spu and general purpose CPU (or TM) is that Spu
       has no ´register´ nor ´flag´, Spu has only a tape. The tape is initially
       empty. Every object (referred to as tape variable) in the tape is  allo‐
       cated via instruction Alloc and identified by a continuous index number.
       Tape variable can be any C++ type, including Spu.

       The  instruction  of Spu is application definable. Except necessary few,
       about  >30  instructions  are  defined  for  convenience,  see   manpage
       Wy.Sct(3wy).

       Documentation following omits the scope name Wy::Sct for each occurrence
       of Spu for clearity.

PUBLIC MEMBERS
        class Reply
        typedef ssize_t IndexType
        Spu()
        ~Spu()

        InstrIdx next_instr
        Array<InstrIdx> istack
        Array<unsign char> tape
        PtrArray<InstrBase> program

        template<T> const T& get_data(IndexType) const
        template<T> T& get_data(IndexType)
        void set_instr_base(Spu&)
        Errno run(InstrIdx)
        Errno step()
        void add_instr(InstrBase*)

AUXILIARY FUNCTIONS
        SPU_INSTR(x)
        Errno fix_label(Spu&)
        constexpr InstrIdx Label(void*)
...[cut]

As seen, OOP in the view of TM is about the concept of analysis and processing
of programming problems (centered around 'object' created and destructed), less
about the prgramming language being used.
libwy's OOP (ClassGuidelines.txt
https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
) made it preciser as written guidelines rather than 'philosophical talk'.

 Follow the guidelines, so that:
 1. the 'programmable concept' can be much universal and solid.
 2. It makes the programmer know whether its concept of programming idea is
    proper or not in as early as it is used, significantly reducing the workload
    of software development (design+implement+maintenence+development).

Note: class Spu itself is one of the few cases not fit ClassGuidelines well (for reasons).

Talk of the OOP concept is not easy, ClassGuidelines has been practiced for

20 years and still valid, and the applicability is still growing.