Path: ...!Xl.tags.giganews.com!local-2.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 10 Dec 2024 01:44:01 +0000
Subject: Re: What is OOP? --- The most important aspect of OOP
Newsgroups: comp.lang.c++
References: <d8a5a0d563f0b9b78b34711d12d4975a7941f53a.camel@gmail.com>
 <86frn6og85.fsf@linuxsc.com> <vj0cj5$2n835$1@dont-email.me>
 <90e75c71c42fcf43b89644a46a60e4fff63ecc10@i2pn2.org>
 <86ldwoiw39.fsf@linuxsc.com>
From: Ross Finlayson <ross.a.finlayson@gmail.com>
Date: Mon, 9 Dec 2024 17:43:52 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <86ldwoiw39.fsf@linuxsc.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <qducnViRZ6h_Acr6nZ2dnZfqn_SdnZ2d@giganews.com>
Lines: 111
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-47wdPUpJfsx6UIqsnfUAu70XEHUVPrkY9QoMTNybPnES0hQittaR/C40hxIP3O4ddZpJeJPYwO2FLU5!TNOWCMVhytsRUOcuH1SQFBZwy8N+2ee8piOl8mGkEmZ2GS9KLMrkAMDTqx91fyakdpHvMvHcNWY=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 5958

On 12/09/2024 09:51 AM, Tim Rentsch wrote:
> Richard Damon <richard@damon-family.org> writes:
>
>> 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.
>
> I agree with the first paragraph, because of the word "normally".  I
> think it's important to add that there is no inherent incompatibility
> between object-oriented programming and functional programming.  There
> are ways to work with classes and objects in a fully functional mode,
> in much the same way that one can write code for data structures such
> as AVL trees or B-trees that is fully functional (so there are no side
> effects to existing trees when adding or deleting elements, for
> example).
>

One might call this "idempotent" or "monadic",
vis-a-vis "pure", in the functional programming.

The idea of "no side effects" then also has for
usually that "idempotent" includes "repeatable,
with no side effects", i.e. usually "repeatable
to attempt until success, transactional", or
"repeatable to attempt, idempotent", then with
regards to the monadic that the entire body of
co-routines is all collected and a thing, while
"pure" functions usually mean idempotent, side-effect
free and also returning the same result for the
same inputs.

Not to be confused with "pure virtual" or abstract
methods, say.

Often goals these days include "idempotent routine"
since thusly when "Murphy's law arbitrarily fails
any routine", then thusly what's often "retry-logic"
or "error mode", or "failure mode", makes for what's
usually in "distributed systems" the "eventually
consistent" and "self-healing".

I don't see these so much in classic pattern lit-rature
though it's very widely held knowledge.

Because Murphy's law in distributed systems, ....

Functional programming doesn't exclude "side-effects",
per se.