Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124903
Precedence: bulk
MIME-Version: 1.0
References: <CAM7F2--3o6kD+2QgV+KuWZsU=CLPh9vsNU8xqApcswTDqAvoVw@mail.gmail.com>
 <5234A623-AAB4-422D-B0C9-F2F9BD0DBF69@getmailspring.com>
In-Reply-To: <5234A623-AAB4-422D-B0C9-F2F9BD0DBF69@getmailspring.com>
Date: Mon, 12 Aug 2024 12:59:37 -0600
Message-ID: <CAM7F2-_i58wfkdspFRGcsDLBp8eDB2aby5ENym3KpWAf+Tq6bw@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API
To: John Coggeshall <john@coggeshall.org>
Cc: Levi Morrison <levi.morrison@datadoghq.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000da2851061f81184f"
From: lnearwaju@gmail.com (Lanre)

--000000000000da2851061f81184f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 12, 2024 at 12:33=E2=80=AFPM John Coggeshall <john@coggeshall.o=
rg>
wrote:

>
>
> On Aug 12 2024, at 12:27 pm, Lanre <lnearwaju@gmail.com> wrote:
>
>
>
> On Mon, Aug 12, 2024 at 9:58=E2=80=AFAM John Coggeshall <john@coggeshall.=
org>
> wrote:
>
>
> > I=E2=80=99m considering adding some C++ enhancements to the Zend API.
>
>
> I would definitely like to see an RFC 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 less
> secure, and harder to maintain codebase. The win of making it easier /
> "nicer" on a subset of developers who might prefer a C++ interface isn't
> anywhere near worth the risk IMO.
>
>
> You aren't making any sense. Why would we remove the old way? Or why
> should that be a prerequisite to improving the current API? How are
> functions that simply proxy the C API inherently 'more brittle, potential=
ly
> less secure, and harder to maintain'? You haven't even seen the code in
> question?
>
>
> 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.
>
> FWIW I agree 100% with Pierre as well -- both his political and
> non-political answer :) --  if the project was to consider anything I'd
> love to see Rust get some love.
>
>
>
>
>
I didn=E2=80=99t realize this was an open mic for Rust devs to flaunt their
ignorance, but since you=E2=80=99ve decided to chime in, let me spell it ou=
t for
you. Rust has absolutely nothing to do with this discussion, so try to stay
on topic. Nowhere did I mention a move to C++; perhaps reading
comprehension isn=E2=80=99t your strong suit.

PHP already supports C++ for extensions, as evidenced by the intl
extension. The current support is painfully basic, which forces developers
to waste time on redundant wrappers or use third-party libraries like
PHP-CPP. What I=E2=80=99m proposing is a way to improve this support so C++=
 devs
don=E2=80=99t have to keep doing the same menial work over and over again.

All of this will be wrapped in macros, so C compilers won=E2=80=99t even no=
tice the
compatibility layer and will compile as usual. It=E2=80=99s a simple, elega=
nt
solution=E2=80=94something you might not be familiar with, given your affin=
ity for
Rust=E2=80=99s convoluted approach to everything.

Cheers,
Lanre.

--000000000000da2851061f81184f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 12, 2024 at 12:33=E2=80=
=AFPM John Coggeshall &lt;<a href=3D"mailto:john@coggeshall.org">john@cogge=
shall.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><br><br><div>On Aug 12 2024, at 12:27 pm, Lanre &lt;<a href=3D"m=
ailto:lnearwaju@gmail.com" target=3D"_blank">lnearwaju@gmail.com</a>&gt; wr=
ote:</div><blockquote><div><div><br></div><br><div class=3D"gmail_quote"><d=
iv class=3D"gmail_attr"><div>On Mon, Aug 12, 2024 at 9:58=E2=80=AFAM John C=
oggeshall &lt;<a href=3D"mailto:john@coggeshall.org" title=3D"mailto:john@c=
oggeshall.org" target=3D"_blank">john@coggeshall.org</a>&gt; wrote:</div></=
div><blockquote><br><blockquote><div><div>&gt; I=E2=80=99m considering addi=
ng some C++ enhancements to the Zend API.</div></div></blockquote><br><div>=
I would definitely like to see an RFC for this if it was to be considered. =
To me, adding a whole new way of doing things internally without completely=
 removing the old way is just asking for a more brittle, potentially less s=
ecure, and harder to maintain codebase. The win of making it easier / &quot=
;nicer&quot; on a subset of developers who might prefer a C++ interface isn=
&#39;t anywhere near worth the risk IMO.</div></blockquote><div><br></div><=
div>You aren&#39;t making any sense. Why would we remove the old way? Or wh=
y should that be a prerequisite to improving the current API? How are funct=
ions that simply proxy the C API inherently &#39;more brittle, potentially =
less secure, and harder to maintain&#39;? You haven&#39;t even seen the cod=
e in question?</div></div></div></blockquote><div><div class=3D"gmail_quote=
"><br><div>I think I&#39;m making perfect sense. I don&#39;t think it&#39;s=
 a good idea to have two ways of doing the same thing. Having two ways mean=
s twice the tests, twice the potential security issues, and twice the maint=
enance. 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 what yo=
u&#39;re implying by your code block), even if the first PR merged starts t=
hat way.</div><br><div>FWIW I agree 100% with Pierre as well -- both his po=
litical and non-political answer :<span>)</span>=C2=A0--=C2=A0 if the proje=
ct was to consider anything I&#39;d love to see Rust get some love. </div><=
br><div>=C2=A0</div><br><br></div></div></blockquote><div><br></div><div>I =
didn=E2=80=99t realize this was an open mic for Rust devs to flaunt their i=
gnorance, but since you=E2=80=99ve decided to chime in, let me spell it out=
 for you. Rust has absolutely nothing to do with this discussion, so try to=
 stay on topic. Nowhere did I mention a move to C++; perhaps reading compre=
hension isn=E2=80=99t your strong suit.<br><br>PHP already supports C++ for=
 extensions, as evidenced by the intl extension. The current support is pai=
nfully basic, which forces developers to waste time on redundant wrappers o=
r use third-party libraries like PHP-CPP. What I=E2=80=99m proposing is a w=
ay to improve this support so C++ devs don=E2=80=99t have to keep doing the=
 same menial work over and over again.<br><br>All of this will be wrapped i=
n macros, so C compilers won=E2=80=99t even notice the compatibility layer =
and will compile as usual. It=E2=80=99s a simple, elegant solution=E2=80=94=
something you might not be familiar with, given your affinity for Rust=E2=
=80=99s convoluted approach to everything.<br></div><div><br></div><div>Che=
ers,</div><div>Lanre.</div></div></div>

--000000000000da2851061f81184f--