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.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Mon, 2025-03-17 at 10:17 -0700, Tim Rentsch wrote:

ram@zedat.fu-berlin.de=C2=A0(Stefan Ram) writes:
=20

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

what is oo programming?

=20
=C2=A0 Alan Kay coined the term, and, in 2003, I asked him:
=20
What does "object-oriented [programming]" mean to you?
=20
=C2=A0 . He answered in an e-mail:
=20

OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things.

=20
=C2=A0 . My personal interpretation (taking the above source and my
=C2=A0 own observations into account):

=20
I appreciate your efforts in pursuing this and in describing what
you think it all means.=C2=A0 I'm glad to see a discussion about OOP
that goes beyond the common misunderstandings of what is meant.
=20
I would like to respond to your comments with my own understanding
of how Alan views these areas.=C2=A0 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.
=20

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

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

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

=20
The key property of object-oriented programming is that sending a
message is the only way to accomplish anything.=C2=A0 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.=C2=A0 There are no data
values as such;=C2=A0 the only kinds of values in OOP are objects.
=20
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.
=20

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

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

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

=20
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.=C2=A0 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).
=20

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

=20
Messages are always sent to objects, not to expressions.
=20
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.
=20
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.
=20

=C2=A0 But there's something else of equal importance!=C2=A0 It's the =C2=A0 insight by Uncle Bob (Robert C. Martin) about when procedural
=C2=A0 code is better and when object-oriented code is better.
=20

Procedural code (code using data structures) makes it easy to
add new functions without changing the existing data
structures.=C2=A0 OO code, on the other hand, makes it easy to add
new classes without changing existing functions.

Robert C. Martin
=20

Procedural code makes it hard to add new data structures
because all the functions must change.=C2=A0 OO code makes it hard
to add new functions because all the classes must change.

Robert C. Martin

=20
Both of these comments make the mistake of conflating OOP with
programming in languages that have classes.=C2=A0 That isn't what Alan
meant by object-oriented programming.=C2=A0 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 me= thod'.
-------
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=E2=80=90
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 =C2=B4register=C2=B4 nor =C2=B4flag=C2=B4, Spu has only a tap=
e. The tape is initially
empty. Every object (referred to as tape variable) in the tape is a= llo=E2=80=90
cated via instruction Alloc and identified by a continuous index num= ber.
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 man= page
Wy.Sct(3wy).

Documentation following omits the scope name Wy::Sct for each occurr= ence
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 process= ing
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 wor= kload
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.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Wed, 2025-03-19 at 04:58 +0800, wij wrote:

On Mon, 2025-03-17 at 10:17 -0700, Tim Rentsch wrote:

ram@zedat.fu-berlin.de=C2=A0(Stefan Ram) writes:
=20

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

what is oo programming?

=20
=C2=A0 Alan Kay coined the term, and, in 2003, I asked him:
=20
What does "object-oriented [programming]" mean to you?
=20
=C2=A0 . He answered in an e-mail:
=20

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

=20
=C2=A0 . My personal interpretation (taking the above source and my =C2=A0 own observations into account):

=20
I appreciate your efforts in pursuing this and in describing what
you think it all means.=C2=A0 I'm glad to see a discussion about OOP
that goes beyond the common misunderstandings of what is meant.
=20
I would like to respond to your comments with my own understanding
of how Alan views these areas.=C2=A0 I should explain that I have talke=

d

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.
=20

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

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

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

=20
The key property of object-oriented programming is that sending a
message is the only way to accomplish anything.=C2=A0 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.=C2=A0 There are no data
values as such;=C2=A0 the only kinds of values in OOP are objects.
=20
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.
=20

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

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

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

=20
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.=C2=A0 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).
=20

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

=20
Messages are always sent to objects, not to expressions.
=20
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.
=20
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.
=20

=C2=A0 But there's something else of equal importance!=C2=A0 It's the =C2=A0 insight by Uncle Bob (Robert C. Martin) about when procedural =C2=A0 code is better and when object-oriented code is better.
=20

Procedural code (code using data structures) makes it easy to
add new functions without changing the existing data
structures.=C2=A0 OO code, on the other hand, makes it easy to add
new classes without changing existing functions.

Robert C. Martin
=20

Procedural code makes it hard to add new data structures
because all the functions must change.=C2=A0 OO code makes it hard
to add new functions because all the classes must change.

Robert C. Martin

=20
Both of these comments make the mistake of conflating OOP with
programming in languages that have classes.=C2=A0 That isn't what Alan meant by object-oriented programming.=C2=A0 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.

=20
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)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=

=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Wy.Sct.Spu(3wy)

=20
NAME
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Spu - Class of general purpose Soft-=

CPU

=20
SYNOPSIS
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Except POD types, C structures, all =

types are declared in namespace Wy.

=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #include <CSCall/Sct.h>
=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Spu=C2=A0 (Soft=C2=A0 CPU)=C2=A0 is=

=C2=A0 a revised model of Turing Machine and a class that

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 acts like a general purpose CPU-base=

d computing machine to=C2=A0 provide=C2=A0 se=E2=80=90

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mantics for computing language and f=

or remote program communication.

=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The=C2=A0 main differences of Spu an=

d general purpose CPU (or TM) is that Spu

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 has no =C2=B4register=C2=B4 nor =C2=

=B4flag=C2=B4, Spu has only a tape. The tape is initially

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 empty. Every object (referred to as =

tape variable) in the tape is=C2=A0 allo=E2=80=90

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cated via instruction Alloc and iden=

tified by a continuous index number.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tape variable can be any C++ type, i=

ncluding Spu.

=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The=C2=A0 instruction=C2=A0 of Spu i=

s application definable. Except necessary few,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 about=C2=A0 >30=C2=A0 instructions=

=C2=A0 are=C2=A0 defined=C2=A0 for=C2=A0 convenience,=C2=A0 see=C2=A0=C2=A0=
manpage

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Wy.Sct(3wy).
=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Documentation following omits the sc=

ope name Wy::Sct for each occurrence

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of Spu for clearity.
=20
PUBLIC MEMBERS
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 class Reply =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 typedef ssize_t IndexType =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Spu() =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ~Spu()
=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 InstrIdx next_instr =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Array<InstrIdx> istack =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Array<unsign char> tape =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PtrArray<InstrBase> program
=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template<T> const T& get_data(=

IndexType) const

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template<T> T& get_data(IndexT=

ype)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void set_instr_base(Spu&) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Errno run(InstrIdx) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Errno step() =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void add_instr(InstrBase*)
=20
AUXILIARY FUNCTIONS
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SPU_INSTR(x) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Errno fix_label(Spu&) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 constexpr InstrIdx Label(void*=

)

...[cut]
=20
As seen, OOP in the view of TM is about the concept of analysis and proce=

ssing

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.tx=

t/download

) made it preciser as written guidelines rather than 'philosophical talk'=

..

=20
=C2=A0Follow the guidelines, so that:
=C2=A01. the 'programmable concept' can be much universal and solid.
=C2=A02. It makes the programmer know whether its concept of programming =

idea is

=C2=A0=C2=A0=C2=A0 proper or not in as early as it is used, significantly=

reducing the workload

=C2=A0=C2=A0=C2=A0 of software development (design+implement+maintenence+=

development).

=20
Note: class Spu itself is one of the few cases not fit ClassGuidelines we=

ll (for reasons).

=20
Talk of the OOP concept is not easy, ClassGuidelines has been practiced f=

or

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

=20

So, the basics of OO is the very concept of object, which is particularily realized in C++ by ctor (equivalent to init/open(..), close(..) in C).
libwy defines the semantics and several other access functions
1=E3=80=82ctor,and associated reset functions.
2. const member functions identify the 'attribute' of the created object.
(Most attribute functions are class specific. libwy defines one: is_def= ault)
3. non-constmemers modifies attributes. In principle, what is modified mus=
t be
'visible' or test-able.

Looks not much different, too simple?=20
Every new class (and written class) will encounter the same problems above = again
and again: What the role or class member should be?=C2=A0
Most problems found (in libwy's view) are: 1. Attributes of class are not c= lear.
What follow are inconsistent functionality of access members.=C2=A0If this =
is not clear
'correctness' is difficult to talk about. 2. the function of=C2=A0assignmen=
t and copy=C2=A0
ctor are not quite the same.

Many software problems are from these simple basics (semantics of concept/c= lass).
If not correctly solved, further development won't go far.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Mon, 17 Mar 2025 10:17:51 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

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.

It sounds like very flexible paradigm that I very certainly don't want
to use.
I like majority of my mistakes caught in compile/link/load time rather
than in run time.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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

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

ram@zedat.fu-berlin.de=C2=A0(Stefan Ram) writes:
=20

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

what is oo programming?

=20
=C2=A0 Alan Kay coined the term, and, in 2003, I asked him:
=20
What does "object-oriented [programming]" mean to you?
=20
=C2=A0 . He answered in an e-mail:
=20

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

=20
=C2=A0 . My personal interpretation (taking the above source and my o=

wn

=C2=A0 observations into account):

=20
I appreciate your efforts in pursuing this and in describing what you
think it all means.=C2=A0 I'm glad to see a discussion about OOP that g=

oes

beyond the common misunderstandings of what is meant.
=20
I would like to respond to your comments with my own understanding of
how Alan views these areas.=C2=A0 I should explain that I have talked w=

ith

(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.
=20

An object is an imaginary building block that contains states and procedures and can only be accessed from the outside by sending messages.=C2=A0 The object decides how it reacts (within the scope of=

its

specification) to a specific message.=C2=A0 (runtime model)

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

In object-oriented programming, programs describe under which
conditions which messages are sent to object expressions at runtime:=

=20

For this purpose, there is a dispatch specification that defines the recipient object expression and the message to be sent.=C2=A0 This di=

spatch

definition can also be regarded as an expression whose value is then determined by the recipient object (as a type of response).=C2=A0 (so=

urce

code model)

=20
The key property of object-oriented programming is that sending a
message is the only way to accomplish anything.=C2=A0 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.=C2=A0 There are no data values as such;=C2=A0 =

the only

kinds of values in OOP are objects.
=20
In addition to sending messages, Smalltalk has ways of using identifier=

s

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 thes=

e

capabilities are secondary to the key property described in the previou=

s

paragraph.
=20

It must be possible to determine which object receives a particular message (late binding) as late as possible (i.e. at runtime during th=

e

evaluation of the dispatch determination):

=20
The late binding that Alan is talking about is the binding of messages
to processing activity.=C2=A0 Note the contrast with calling a function=

,

where the binding of name to what processing is done is static rather
than deferred.
=20

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

=20
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.=

=20

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

=C2=A0 Yes, I really think it is better to say that we send messages =

to

=C2=A0 expressions because which object the expression represents is =

only

=C2=A0 determined shortly beforehand and can be different each time t=

he same

=C2=A0 code is run several times.

=20
Messages are always sent to objects, not to expressions.
=20
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.
=20
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 t=

o

what processing activity will occur always takes place at the last
possible moment.
=20

=C2=A0 But there's something else of equal importance!=C2=A0 It's the=

insight by

=C2=A0 Uncle Bob (Robert C. Martin) about when procedural code is bet=

ter and

=C2=A0 when object-oriented code is better.
=20

Procedural code (code using data structures) makes it easy to |add =

new

functions without changing the existing data |structures.=C2=A0 OO co=

de, on

the other hand, makes it easy to add |new classes without changing existing functions.
Robert C. Martin
=20

Procedural code makes it hard to add new data structures |because a=

ll

the functions must change.=C2=A0 OO code makes it hard |to add new fu=

nctions

because all the classes must change.
Robert C. Martin

=20
Both of these comments make the mistake of conflating OOP with
programming in languages that have classes.=C2=A0 That isn't what Alan =

meant

by object-oriented programming.=C2=A0 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.

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

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


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Sat, 29 Mar 2025 11:12:08 +0800
wij <wyniijj5@gmail.com> wrote:

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

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

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

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

what is oo programming? =20

=20
=A0 Alan Kay coined the term, and, in 2003, I asked him:
=20
What does "object-oriented [programming]" mean to you?
=20
=A0 . He answered in an e-mail:
=20

OOP to me means only messaging, local retention and
protection and hiding of state-process, and extreme
late-binding of all things. =20

=20
=A0 . My personal interpretation (taking the above source and my
own observations into account): =20

=20
I appreciate your efforts in pursuing this and in describing what
you think it all means.=A0 I'm glad to see a discussion about OOP
that goes beyond the common misunderstandings of what is meant.
=20
I would like to respond to your comments with my own
understanding of how Alan views these areas.=A0 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.=20

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

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

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.=A0 This dispatch definition can also be regarded as an expression whose value is then determined by the recipient
object (as a type of response).=A0 (source code model) =20

=20
The key property of object-oriented programming is that sending a
message is the only way to accomplish anything.=A0 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.=A0 There are no data
values as such;=A0 the only kinds of values in OOP are objects.
=20
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.
=20

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): =20

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

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

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

=A0 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. =20

=20
Messages are always sent to objects, not to expressions.
=20
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.
=20
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.
=20

=A0 But there's something else of equal importance!=A0 It's the
insight by Uncle Bob (Robert C. Martin) about when procedural
code is better and when object-oriented code is better.
=20

Procedural code (code using data structures) makes it easy to
|add new =20

functions without changing the existing data |structures.=A0 OO
code, on the other hand, makes it easy to add |new classes
without changing existing functions.
Robert C. Martin
=20

Procedural code makes it hard to add new data structures
|because all =20

the functions must change.=A0 OO code makes it hard |to add new functions because all the classes must change.
Robert C. Martin =20

=20
Both of these comments make the mistake of conflating OOP with programming in languages that have classes.=A0 That isn't what Alan
meant by object-oriented programming.=A0 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. =20

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

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

Correct.



--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Michael S <already5chosen@yahoo.com> writes:

On Mon, 17 Mar 2025 10:17:51 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

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.

It sounds like very flexible paradigm that I very certainly don't want
to use.
I like majority of my mistakes caught in compile/link/load time rather
than in run time.

It's important to understand that object-oriented programming is
more about mindset than it is about any particular set of language
features. In particular, OOP is not incompatible with strong type
checking, especially under the "majority" criterion. There are
languages with classes and inheritance that also impose strict type
checking (OCaml is one example), which I think would get you the
property you want of catching most mistakes before run time. I
don't mean to suggest that a combination "ideal OOP" and perfect
type checking is a solved problem, it isn't. My sense though is
that languages that are available now can supply between 80 and 90
percent of both. You might want to try looking into whether that
could do what you want.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Mr Flibble <flibble@reddwarf.jmc.corp> writes:

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

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

[...]

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

Your view of object-oriented programs is different from Alan Kay's view
of object-oriented programming.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)