OTOH, in C/C++, every memory objects/function has address, the language cannot
pretend it is not actually dealing with a large array of raw 'bytes' and its restrictions (and restrict by Turing Machine). I think that is generally where
many programming problems from. And, understanding C or assembly is nearly a must
before understanding C++, otherwise, no real meaning, simply put.
There are several understandings: https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming
...
OO can have many meaning. I took OO to mean object, the basic entity
of the programming model and the operation of the object. The
concept, as foundmental, has to be solid, practical and easily
usable. Otherwise, more codes and efforts will be needed latter to
fix it, making the original goal ,practically, a lie. IOW, (nearly) a flawless model is all the basics. ... https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
From my view, programming language has to provide a model, so that programmers know what they are dealing with, to solve the problem
(recent C++ seems solving just syntax problems).
In (my) OOP, 'portability' (or reusable) is first achieved by making
the probramming object compatible (form platform to platfrom or from
time to time in the same platform, but libwy only considers linux,
but the idea should be generally applicable), i.e. like pod types, structures, union may not be portable.
Programming object or 'concept' are 'better' represented/wrapped by
class (keyword) All should be simple, I don't know how to make the
idea of 'object' more simpler. See the guidelines.
OTOH, in C/C++, every memory objects/function has address, the
language cannot pretend it is not actually dealing with a large array
of raw 'bytes' and its restrictions (and restrict by Turing Machine).
I think that is generally where many programming problems from. And, understanding C or assembly is nearly a must before understanding
C++, otherwise, no real meaning, simply put.
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.
On Sun, 2024-12-01 at 17:02 -0500, Richard Damon wrote:
On 12/1/24 12:17 PM, wij wrote:
OTOH, in C/C++, every memory objects/function has address, the language cannot
pretend it is not actually dealing with a large array of raw 'bytes' and its
restrictions (and restrict by Turing Machine). I think that is generally where
many programming problems from. And, understanding C or assembly is nearly a must
before understanding C++, otherwise, no real meaning, simply put.
Except that by the rules of pointes in C (and C++) you can not convert a
pointer to one object to a pointer to some other object that isn't
within some defined larger object that the first object was also in.
While you can convert any pointer to some interger type, or into a char*
pointer, there is nothing that gaurentes that these somehow correspond
to "raw memory" address in some big raw memory array that you can go
elsewhere with.
Yes, currently with most processors, it will just work, but nothing
requires that to work, and in previous segmented architectures, it
simply wasn't true.
My point is that object is eventually a piece of consecutive 'raw' bytes in the
'big array'. We don't know how hardware might actully be, but C/C++ will make it like a big array (there might be gaps). Human recognition is makeup. Although we try hard to make the raw bytes recognizable, the dangerous thing is
pretending it is not or unaware what it is when programming in C/C++.
The easiest proof is using debugger. Sounds easy? but not, as it appears.
E.g. if the programer doesn't understand what the stack is (C++ pretty much avoid talking about it), his/her C/C++ program would be suspicious because we don't know when 'Segmentation fault' would happen. How do you verify correctness
just by the program 'logic'?
There are several understandings: >https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming
...
OO can have many meaning. I took OO to mean object, the basic entity of the >programming model and the operation of the object. The concept, as foundmental,
has to be solid, practical and easily usable. Otherwise, more codes and efforts
will be needed latter to fix it, making the original goal ,practically, a lie. >IOW, (nearly) a flawless model is all the basics. ... >https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
From my view, programming language has to provide a model, so that programmers >know what they are dealing with, to solve the problem (recent C++ seems solving
just syntax problems).
In (my) OOP, 'portability' (or reusable) is first achieved by making the >probramming object compatible (form platform to platfrom or from time to time >in the same platform, but libwy only considers linux, but the idea should be >generally applicable), i.e. like pod types, structures, union may not be portable.
Programming object or 'concept' are 'better' represented/wrapped by class (keyword)
All should be simple, I don't know how to make the idea of 'object' more simpler.
See the guidelines.
How do you verify correctness just by the program 'logic'?
On Sun, 01 Dec 2024 20:34:34 -0800
Tim Rentsch <tr.17687@z991.linuxsc.com> 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.
Finding the author of the quote is left as an exercise to the
reader :-)
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.
In the finishing part of the second quate Alan Key is wrong.
"Notions of activity, communication and inheritance" are less
rather than more generally useful than algorithms (procedures)
and their accompanying data structures.
But that does not answer original question, so O.T.
But that does not answer original question, so O.T.
His comment about activity and so forth is very much relevant to
his view of what "object-oriented programming" means (to the
extent that I understand what he has said and was trying to say
in that comment).
On Sun, 15 Dec 2024 04:24:20 -0800
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
But that does not answer original question, so O.T.
His comment about activity and so forth is very much relevant to
his view of what "object-oriented programming" means (to the
extent that I understand what he has said and was trying to say
in that comment).
How many words (rough estimate) are required to answer the original
question?
Your answer to Janis Papanagnou approximately a week ago seems to
suggest that 10,000 words are likely to not suffice, even if those are
words of Alan Key himself. OTOH, relatively short demos have better
chance.
Or do demos have better chance only due to 10,000 words that preceded
them?
what is oo programming?
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
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 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: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 55:16:44 |
| Calls: | 10,397 |
| Calls today: | 5 |
| Files: | 14,067 |
| Messages: | 6,417,425 |
| Posted today: | 1 |