Path: ...!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: Sat, 29 Mar 2025 11:12:08 +0800
Organization: A noiseless patient Spider
Lines: 162
Message-ID: <d91209a9f28fcdd7d9137b24bc36c7d02b3ca930.camel@gmail.com>
References: <d8a5a0d563f0b9b78b34711d12d4975a7941f53a.camel@gmail.com>
		<gog0ljdjdhdekscrcbpprte8788aerq05h@4ax.com>
		<OOP-20241218203833@ram.dialup.fu-berlin.de> <86h63rr2yo.fsf@linuxsc.com>
	 <fIgFP.1495528$gHk7.785173@fx17.ams4>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sat, 29 Mar 2025 04:12:10 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c9af4106d94f1e8324be648c1c4a2407";
	logging-data="215874"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/SKI7kCroHz05HErOdX8OZ"
User-Agent: Evolution 3.54.3 (3.54.3-1.fc41)
Cancel-Lock: sha1:oc3Hct9+BpNNPlv4o+qpw+XE5og=
In-Reply-To: <fIgFP.1495528$gHk7.785173@fx17.ams4>
Bytes: 8010

On Thu, 2025-03-27 at 18:23 +0000, Mr Flibble wrote:
> On Mon, 17 Mar 2025 10:17:51 -0700, Tim Rentsch wrote:
>=20
> > ram@zedat.fu-berlin.de=C2=A0(Stefan Ram) writes:
> >=20
> > > Rosario19 <Ros@invalid.invalid> wrote or quoted:
> > >=20
> > > > what is oo programming?
> > >=20
> > > =C2=A0 Alan Kay coined the term, and, in 2003, I asked him:
> > >=20
> > > What does "object-oriented [programming]" mean to you?
> > >=20
> > > =C2=A0 . He answered in an e-mail:
> > >=20
> > > > OOP to me means only messaging, local retention and protection and
> > > > hiding of state-process, and extreme late-binding of all things.
> > >=20
> > > =C2=A0 . My personal interpretation (taking the above source and my o=
wn
> > > =C2=A0 observations into account):
> >=20
> > I appreciate your efforts in pursuing this and in describing what you
> > think it all means.=C2=A0 I'm glad to see a discussion about OOP that g=
oes
> > beyond the common misunderstandings of what is meant.
> >=20
> > I would like to respond to your comments with my own understanding of
> > how Alan views these areas.=C2=A0 I should explain that I have talked w=
ith
> > (and also listened to) Alan enough so that I think I have a pretty good
> > understanding of what his views are here, but the comments below are
> > just my impression of his thoughts.
> >=20
> > > An object is an imaginary building block that contains states and
> > > procedures and can only be accessed from the outside by sending
> > > messages.=C2=A0 The object decides how it reacts (within the scope of=
 its
> > > specification) to a specific message.=C2=A0 (runtime model)
> >=20
> > An object is a blob about which nothing is known except that it is able
> > to receive messages and act on them (which may include doing nothing at
> > all).
> >=20
> > > In object-oriented programming, programs describe under which
> > > conditions which messages are sent to object expressions at runtime:=
=20
> > > For this purpose, there is a dispatch specification that defines the
> > > recipient object expression and the message to be sent.=C2=A0 This di=
spatch
> > > definition can also be regarded as an expression whose value is then
> > > determined by the recipient object (as a type of response).=C2=A0 (so=
urce
> > > code model)
> >=20
> > The key property of object-oriented programming is that sending a
> > message is the only way to accomplish anything.=C2=A0 Sending a message=
 may
> > start an activity and never return, or it may finish and return an
> > object value, with the understanding that "object value" always means
> > using pointer semantics.=C2=A0 There are no data values as such;=C2=A0 =
the only
> > kinds of values in OOP are objects.
> >=20
> > In addition to sending messages, Smalltalk has ways of using identifier=
s
> > to refer to an object, of combining or sequencing message send
> > constructs, and of assigning an object value (which again uses pointer
> > semantics) to a named object holder (some form of identifier), but thes=
e
> > capabilities are secondary to the key property described in the previou=
s
> > paragraph.
> >=20
> > > It must be possible to determine which object receives a particular
> > > message (late binding) as late as possible (i.e. at runtime during th=
e
> > > evaluation of the dispatch determination):
> >=20
> > The late binding that Alan is talking about is the binding of messages
> > to processing activity.=C2=A0 Note the contrast with calling a function=
,
> > where the binding of name to what processing is done is static rather
> > than deferred.
> >=20
> > > For this purpose, the recipient object can be specified again in the
> > > dispatch determination itself by means of an expression that is only
> > > evaluated at runtime as late as possible (runtime polymorphism).
> >=20
> > It's true that the returned object value of a sent message can be used
> > to send a further message, but that is not an occurrence of binding.=
=20
> > Calling a function through a pointer-to-function relies on information
> > known only at runtime, but no binding is taking place for that (except
> > perhaps for the mapping of a variable name to a location holding the
> > pointer-to-function value).
> >=20
> > > =C2=A0 Yes, I really think it is better to say that we send messages =
to
> > > =C2=A0 expressions because which object the expression represents is =
only
> > > =C2=A0 determined shortly beforehand and can be different each time t=
he same
> > > =C2=A0 code is run several times.
> >=20
> > Messages are always sent to objects, not to expressions.
> >=20
> > Obviously determining an object value at runtime is useful, but it isn'=
t
> > any different than determining any other value at runtime. Calling a
> > function in C that takes two arguments and returns their sum depends on
> > values determined at runtime, but that nothing to do with late binding.
> >=20
> > The key point is that, having gotten back an object, we can't do
> > anything with it except send it a message, and the binding of message t=
o
> > what processing activity will occur always takes place at the last
> > possible moment.
> >=20
> > > =C2=A0 But there's something else of equal importance!=C2=A0 It's the=
 insight by
> > > =C2=A0 Uncle Bob (Robert C. Martin) about when procedural code is bet=
ter and
> > > =C2=A0 when object-oriented code is better.
> > >=20
> > > > Procedural code (code using data structures) makes it easy to |add =
new
> > > functions without changing the existing data |structures.=C2=A0 OO co=
de, on
> > > the other hand, makes it easy to add |new classes without changing
> > > existing functions.
> > > Robert C. Martin
> > >=20
> > > > Procedural code makes it hard to add new data structures |because a=
ll
> > > the functions must change.=C2=A0 OO code makes it hard |to add new fu=
nctions
> > > because all the classes must change.
> > > Robert C. Martin
> >=20
> > Both of these comments make the mistake of conflating OOP with
> > programming in languages that have classes.=C2=A0 That isn't what Alan =
meant
> > by object-oriented programming.=C2=A0 That Smalltalk has classes is
> > incidental to what is meant by object-oriented programming; classes in
> > Smalltalk are simply a way of implementing the abstract idea of
> > "object-oriented programming" that had started in Alan's thinking, and
> > actually much earlier than Smalltalk or even Simula.
>=20
> Wrong. OOP is:
>=20
> * Encapsulation
> * Inheritance
> * Polymorphism (including LSP)
> * Abstractions
>=20
> The above necessitates the need for classes or similar.
>=20
> /Flibble

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