Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: wij <wyniijj5@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: What is OOP?
Date: Thu, 20 Mar 2025 23:04:45 +0800
Organization: A noiseless patient Spider
Lines: 258
Message-ID: <c9e58dcf33e725e48f155b85081f7b1cdd3f8a28.camel@gmail.com>
References: <d8a5a0d563f0b9b78b34711d12d4975a7941f53a.camel@gmail.com>
		 <gog0ljdjdhdekscrcbpprte8788aerq05h@4ax.com>
		 <OOP-20241218203833@ram.dialup.fu-berlin.de> <86h63rr2yo.fsf@linuxsc.com>
	 <05cc45c4b6e94f85bf7d5999f5bf5a88dd79c1b7.camel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Thu, 20 Mar 2025 16:04:49 +0100 (CET)
Injection-Info: dont-email.me; posting-host="0d039cf101f5ca85a9d7be2c9a676daf";
	logging-data="3611499"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/jj+FUo+vCPWoiG7xrUHr0"
User-Agent: Evolution 3.54.3 (3.54.3-1.fc41)
Cancel-Lock: sha1:Ol/WCtgL+pXjzSCigx1FEs4lUhE=
In-Reply-To: <05cc45c4b6e94f85bf7d5999f5bf5a88dd79c1b7.camel@gmail.com>
Bytes: 13651

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
========== REMAINDER OF ARTICLE TRUNCATED ==========