Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124895
Precedence: bulk
MIME-Version: 1.0
References: <CAAKU0unG1ZOmzE=YnbTTmNpsuJr1PX--79fjByC473KHzN008w@mail.gmail.com>
 <3F5C5B7F-6EE5-437D-9E4A-4C86EC103E7A@getmailspring.com>
In-Reply-To: <3F5C5B7F-6EE5-437D-9E4A-4C86EC103E7A@getmailspring.com>
Date: Mon, 12 Aug 2024 23:50:22 +0700
Message-ID: <CAEZPtU6g3V_95reCdqX7ZbM_3wf17ECO6fGw9UvLAAenCXEuwg@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>, Lanre <lnearwaju@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a3e897061f7f4a9b"
From: pierre.php@gmail.com (Pierre Joye)

--000000000000a3e897061f7f4a9b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 12, 2024, 11:03=E2=80=AFPM 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.
>


if anything, I would rather go with rust (zig would have my preference ;-).
The benefits would be to have a significant ease to contribute for many.

Neither of c++ or rust would be easy to add. The later would have the huge
advantage to bring a little bit more safety to the extensions APIs.

A less diplomatic answer would be that c++ makes zero sense in 2024 for php
(or any other language), a strong and bold take :)

best,
Pierre

--000000000000a3e897061f7f4a9b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Mon, Aug 12, 2024, 11:03=E2=80=AFPM John Coggeshall=
 &lt;<a href=3D"mailto:john@coggeshall.org">john@coggeshall.org</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><br><blockquote><div><div>&gt; =
I=E2=80=99m considering adding 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 i=
nternally without completely 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 / &quot;nicer&quot; on a subset of developers who migh=
t prefer a C++ interface isn&#39;t anywhere near worth the risk IMO.</div><=
/blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">if anything, I would rather go with rust (zig would =
have my preference ;-). The benefits would be to have a significant ease to=
 contribute for many.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Ne=
ither of c++ or rust would be easy to add. The later would have the huge ad=
vantage to bring a little bit more safety to the extensions APIs.</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">A less diplomatic answer would be=
 that c++ makes zero sense in 2024 for php (or any other language), a stron=
g and bold take :)</div><div dir=3D"auto"><br></div><div dir=3D"auto">best,=
</div><div dir=3D"auto">Pierre</div><div dir=3D"auto"></div></div>

--000000000000a3e897061f7f4a9b--