Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124902
Date: Mon, 12 Aug 2024 14:33:14 -0400
To: Lanre <lnearwaju@gmail.com>
Cc: Levi Morrison <levi.morrison@datadoghq.com>, PHP internals
 <internals@lists.php.net>
Message-ID: <5234A623-AAB4-422D-B0C9-F2F9BD0DBF69@getmailspring.com>
In-Reply-To: <CAM7F2--3o6kD+2QgV+KuWZsU=CLPh9vsNU8xqApcswTDqAvoVw@mail.gmail.com>
References: <CAM7F2--3o6kD+2QgV+KuWZsU=CLPh9vsNU8xqApcswTDqAvoVw@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66ba556a_19495cff_b101"
From: john@coggeshall.org (John Coggeshall)

--66ba556a_19495cff_b101
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline



On Aug 12 2024, at 12:27 pm, Lanre <lnearwaju=40gmail.com> wrote:
>
>
> On Mon, Aug 12, 2024 at 9:58=E2=80=AFAM John Coggeshall <john=40coggesh=
all.org (mailto:john=40coggeshall.org)> wrote:
> >
> > > > I=E2=80=99m considering adding some C++ enhancements to the Zend =
API.
> > I would definitely like to see an R=46C for this if it was to be cons=
idered. To me, adding a whole new way of doing things internally without =
completely removing the old way is just asking for a more brittle, potent=
ially less secure, and harder to maintain codebase. The win of making it =
easier / =22nicer=22 on a subset of developers who might prefer a C++ int=
erface isn't anywhere near worth the risk IMO.
>
> You aren't making any sense. Why would we remove the old way=3F Or why =
should that be a prerequisite to improving the current API=3F How are fun=
ctions that simply proxy the C API inherently 'more brittle, potentially =
less secure, and harder to maintain'=3F You haven't even seen the code in=
 question=3F

I think I'm making perfect sense. I don't think it's a good idea to have =
two ways of doing the same thing. Having two ways means twice the tests, =
twice the potential security issues, and twice the maintenance. This is n=
ot a simple thing you are suggesting -- I highly doubt any move to C++ is=
 going to end as a simple wrapper (which I assume is what you're implying=
 by your code block), even if the first PR merged starts that way.
=46WIW I agree 100% with Pierre as well -- both his political and non-pol=
itical answer :) -- if the project was to consider anything I'd love to s=
ee Rust get some love.


--66ba556a_19495cff_b101
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div class=3D=22gmail=5Fquote=5Fattribution=22>On Aug 12 2024, at=
 12:27 pm, Lanre &lt;lnearwaju=40gmail.com&gt; wrote:</div><blockquote><d=
iv><div><br></div><br><div class=3D=22gmail=5Fquote=22><div class=3D=22gm=
ail=5Fattr=22><div>On Mon, Aug 12, 2024 at 9:58=E2=80=AFAM John Coggeshal=
l &lt;<a href=3D=22mailto:john=40coggeshall.org=22 title=3D=22mailto:john=
=40coggeshall.org=22>john=40coggeshall.org</a>&gt; wrote:</div></div><blo=
ckquote><br><blockquote><div><div>&gt; I=E2=80=99m considering adding som=
e C++ enhancements to the Zend API.</div></div></blockquote><br><div>I wo=
uld definitely like to see an R=46C for this if it was to be considered. =
To me, adding a whole new way of doing things internally without complete=
ly removing the old way is just asking for a more brittle, potentially le=
ss secure, and harder to maintain codebase. The win of making it easier /=
 =22nicer=22 on a subset of developers who might prefer a C++ interface i=
sn't anywhere near worth the risk IMO.</div></blockquote><div><br></div><=
div>You aren't making any sense. Why would we remove the old way=3F Or wh=
y should that be a prerequisite to improving the current API=3F How are f=
unctions that simply proxy the C API inherently 'more brittle, potentiall=
y less secure, and harder to maintain'=3F You haven't even seen the code =
in question=3F</div></div></div></blockquote><div><div class=3D=22gmail=5F=
quote=22><br><div>I think I'm making perfect sense. I don't think it's a =
good idea to have two ways of doing the same thing. Having two ways means=
 twice the tests, twice the potential security issues, and twice the main=
tenance. This is not a simple thing you are suggesting -- I highly doubt =
any move to C++ is going to end as a simple wrapper (which I assume is wh=
at you're implying by your code block), even if the first PR merged start=
s that way.</div><br><div>=46WIW I agree 100% with Pierre as well -- both=
 his political and non-political answer :<span data-emoji-typing=3D=22tru=
e=22>)</span>&nbsp;--&nbsp; if the project was to consider anything I'd l=
ove to see Rust get some love. </div><br><div>&nbsp;</div><br><br></div><=
/div>
--66ba556a_19495cff_b101--