Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124908
Date: Mon, 12 Aug 2024 16:58:54 -0400
To: Lanre <lnearwaju@gmail.com>
Cc: Levi Morrison <levi.morrison@datadoghq.com>, PHP internals
 <internals@lists.php.net>
Message-ID: <D1F37025-DBE6-47F0-BB62-6CEF756E294D@getmailspring.com>
In-Reply-To: <CAM7F2-895zXfqyDLt9C0_WYTkAAP9Q4wG86Xz6pn8xHNE2wfFw@mail.gmail.com>
References: <CAM7F2-895zXfqyDLt9C0_WYTkAAP9Q4wG86Xz6pn8xHNE2wfFw@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66ba778e_6b8b4567_2e99"
From: john@coggeshall.org (John Coggeshall)

--66ba778e_6b8b4567_2e99
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Friend, honest to god you are really not doing yourself any favors here.

You came on this list with a proposal. I think it's a bad idea, and I've enumerated the reasons why I have come to that conclusion:
If it's so easy and transparent to improve support for C++, it could easily exist outside of core as a set of header files to make the lift lighter for someone looking to use it. Sounds like that project already exists (no idea, didn't look into it).
Even if it's "easy" with a few header files, it's still adding a whole new thing required to maintain the project because now someone has to own and maintain a C++ API and every change to the "real" C engine needs a corresponding C++ API update. Who here long-term is going to own that engine-level API and make sure it's "the C++ way"...you? The way you're behaving I wouldn't trust you to not rage-quit today... so who then? What happens if there is a conflict between "the C way" and "the C++ way" in regards to a new engine-level API down the road? What kind of extra thought / energy / consideration do we need to put into engine-level API changes in the future because now we have to maintain two distinct engine APIs?

If it's not so easy and transparent (e.g. requiring us to start modifying the engine because C++ isn't happy), I'm opposed to the idea because conceptually I'd like to see any such effort spent on improving support for a future-looking language. I honestly don't care what that is, but considering Linux's recent embracing of Rust I think that's got some merit to consider. For the record, I don't personally even code in Rust so attacking me like I've got a horse in that race is pretty ridiculous.

I don't believe that just because something is prevalent means it's good. Entire governments are starting to recommend not using C/C++ because of the security risks posed by its non-existent memory safety. If PHP was being written today, it wouldn't have been written in C.

Don't like I don't agree with you? Okay. It's a public mailing list, and everyone here has an opportunity to chime in and voice their opinion. I'll give you a nickel's worth of free advice though -- speaking from personal experience I'd be happy to tell you about over a beer one day -- not only are you violating the rules of the list, but you're not helping your cause and you just look like an @!#%$% who is screaming louder and louder because someone doesn't agree with them. Please stop, for your own sake.

What is 100% clear to me is that, even if there is a good reason to go down this road, IMO it absolutely should go through an RFC process as I said up front because just with what I've thought of enumerated above there are a lot of questions here that I don't see any reason to believe you've thought through, even if I try to ignore your constant insults.
--66ba778e_6b8b4567_2e99
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>=46riend, honest to god you are really not doing yourself any favors=
 here. </div><br><div>You came on this list with a proposal. I think it's=
 a bad idea, and I've enumerated the reasons why I have come to that conc=
lusion:</div><br><ul><li><div>If it's so easy and transparent to improve =
support for C++, it could easily exist outside of core as a set of header=
 files to make the lift lighter for someone looking to use it. Sounds lik=
e that project already exists (no idea, didn't look into it).</div></li><=
li><div>Even if it's =22easy=22 with a few header files, it's still addin=
g a whole new thing required to maintain the project because now someone =
has to own and maintain a C++ API and every change to the =22real=22 C en=
gine needs a corresponding C++ API update. Who here long-term is going to=
 own that engine-level API and make sure it's =22the C++ way=22...you=3F =
The way you're behaving I wouldn't trust you to not rage-quit today... so=
 who then=3F What happens if there is a conflict between =22the C way=22 =
and =22the C++ way=22 in regards to a new engine-level API down the road=3F=
 What kind of extra thought / energy / consideration do we need to put in=
to engine-level API changes in the future because now we have to maintain=
 two distinct engine APIs=3F</div></li><li><div>If it's not so easy and t=
ransparent (e.g. requiring us to start modifying the engine because C++ i=
sn't happy), I'm opposed to the idea because conceptually I'd like to see=
 any such effort spent on improving support for a future-looking language=
. I honestly don't care what that is, but considering Linux's recent embr=
acing of Rust I think that's got some merit to consider. =46or the record=
, I don't personally even code in Rust so attacking me like I've got a ho=
rse in that race is pretty ridiculous.</div></li><li><div>I don't believe=
 that just because something is prevalent means it's good. Entire governm=
ents are starting to recommend not using C/C++ because of the security ri=
sks posed by its non-existent memory safety. If PHP was being written tod=
ay, it wouldn't have been written in C.</div></li></ul><div>Don't like I =
don't agree with you=3F Okay. It's a public mailing list, and everyone he=
re has an opportunity to chime in and voice their opinion. I'll give you =
a nickel's worth of free advice though -- speaking from personal experien=
ce I'd be happy to tell you about over a beer one day -- not only are you=
 violating the rules of the list, but you're not helping your cause and y=
ou just look like an =40=21=23%=24% who is screaming louder and louder be=
cause someone doesn't agree with them. Please stop, for your own sake.</d=
iv><br><div>What is 100% clear to me is that, even if there is a good rea=
son to go down this road, IMO it absolutely should go through an R=46C pr=
ocess as I said up front because just with what I've thought of enumerate=
d above there are a lot of questions here that I don't see any reason to =
believe you've thought through, even if I try to ignore your constant ins=
ults.</div>
--66ba778e_6b8b4567_2e99--