On 12/6/24 9:40 PM, olcott wrote:
On 12/1/2024 10:34 PM, Tim Rentsch wrote:
wij <wyniijj5@gmail.com> writes:
In response to the question of the subject line...
Just because a program is being written in a language that has
functions doesn't mean that what is being done is functional
programming.
Just because a program is being written in a language that has
classes and objects doesn't mean that what is being done is
object-oriented programming.
More than anything else object-oriented programming is a mindset
or a programming methodology.� It helps if the language being
used supports classes, etc, but the methodology can be used even
in languages that don't have them.
A quote:
���� My guess is that object-oriented programming will be in the
���� 1980s what structured programming was in the 1970s.
���� Everyone will be in favor of it.� Every manufacturer will
���� promote his products as supporting it.� Every manager will
���� pay lip service to it.� Every programmer will practice it
���� (differently).� And no one will know just what it is.
That paragraph is taken from a paper written more than 40 years
ago.� The prediction came true with a vengeance, even more than
the author expected.� Most of what has been written about object
oriented programming was done by people who didn't understand it.
Two more quotes, these from Alan Kay:
���� I invented the term "Object Oriented Programming," and C++
���� is not what I had in mind.
���� Though Smalltalk's structure allows the technique now known
���� as data abstraction to be easily (and more generally)
���� employed, the entire thrust of its design has been to
���� supersede the concept of data and procedures entirely;� to
���� replace these with the more generally useful notions of
���� activity, communication, and inheritance.
The most important aspect of OOP is the ability to decompose
a problem into independent component parts. This can eliminate
the side effects in the structured programming model that
result from global data.
Excpet that normally OOP is fully based on the operation resulting in
"side effects" as they mutate the state of the object the methods are
part of.
What this does is not ELIMINATE the side effects, but limits their
scope. A given object type will tend to keep its own state "private" and >interact only with other object via "public" interfaces, allowing us to >limit the scope we need to think of when looking at interactions.
This makes it very different from the "functional" model, where we do
not allow for side-effects.
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):
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)
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)
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):
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).
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.
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
ram@zedat.fu-berlin.de (Stefan Ram) writes:Agreed.
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 toRobert C. Martin
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.
Procedural code makes it hard to add new data structuresRobert C. Martin
because all the functions must change. OO code makes it hard
to add new functions because all the classes must change.
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.
20 years and still valid, and the applicability is still growing.--- Synchronet 3.20c-Linux NewsLink 1.2
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 toRobert C. Martin
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.
Procedural code makes it hard to add new data structuresRobert C. Martin
because all the functions must change. OO code makes it hard
to add new functions because all the classes must change.
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.
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.
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.
On Mon, 17 Mar 2025 10:17:51 -0700, Tim Rentsch wrote:Blind reciting! Or, useless (worse than none, garbage definition).
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 newfunctions 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 allthe 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
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 tofunctions without changing the existing data |structures. OO code,
|add new
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 |becausethe functions must change. OO code makes it hard |to add new
all
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).
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 tofunctions without changing the existing data |structures.� OO
|add new
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 structuresthe functions must change.� OO code makes it hard |to add new
|because all
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).
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:Correct.
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 tofunctions without changing the existing data |structures. OO
|add new
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 structuresthe functions must change. OO code makes it hard |to add new
|because all
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).
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.
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,029 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 180:52:37 |
| Calls: | 13,336 |
| Calls today: | 3 |
| Files: | 186,574 |
| D/L today: |
5,114 files (1,408M bytes) |
| Messages: | 3,356,559 |