Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124892
Precedence: bulk
MIME-Version: 1.0
References: <CAM7F2--PW75jMoZ9Jqfg48gZeWiRhSbYcVUqLOi2OkZnDA6N6Q@mail.gmail.com>
 <CAAKU0unG1ZOmzE=YnbTTmNpsuJr1PX--79fjByC473KHzN008w@mail.gmail.com>
In-Reply-To: <CAAKU0unG1ZOmzE=YnbTTmNpsuJr1PX--79fjByC473KHzN008w@mail.gmail.com>
Date: Mon, 12 Aug 2024 10:19:51 -0600
Message-ID: <CAM7F2-9Vryw9yE5rZxLnKn29xZ9ejT3OvObK-Ag0omdembxb1Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API
To: Levi Morrison <levi.morrison@datadoghq.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000081d39d061f7edd88"
From: lnearwaju@gmail.com (Lanre)

--00000000000081d39d061f7edd88
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 12, 2024 at 9:49=E2=80=AFAM Levi Morrison <levi.morrison@datado=
ghq.com>
wrote:

> On Sun, Aug 11, 2024 at 4:54=E2=80=AFPM Lanre <lnearwaju@gmail.com> wrote=
:
> >
> > Hello,
> >
> > I=E2=80=99m considering adding some C++ enhancements to the Zend API. T=
hese
> changes would be encapsulated within `#ifdef __cplusplus` guards, so they
> wouldn=E2=80=99t interfere with the existing C implementation. The primar=
y goal is
> to provide a nicer interface for extensions while maintaining compatibili=
ty
> with C.
> >
> > Key points:
> > - **Struct-based Approach:** Everything will still use structs=E2=80=94=
no
> classes or non-public/non-static members.
> > - **Isolation:** Any enhancements that can be isolated from the C
> implementation will be, and they will reside in a common `zend_api_cxx`
> header file.
> > - **Proposed Enhancements:**
> >   - Constructors and destructors, along with comparison operator
> overloads for `zval`.
> >   - Constructor overloads for common `zval` initializations.
> >   - Member methods for common `zval` operations.
> >
> > I=E2=80=99m happy to implement and maintain these changes. Since this d=
oesn=E2=80=99t
> affect userland, do you think an RFC is necessary?
> >
> > Also, if anyone has suggestions or ideas for this C++ API, I=E2=80=99d =
love to
> hear them.
> >
> > Cheers,
> > Lanre
>
> I am not opposed, but there are some logistics questions:
>  1. Since it's for extensions and not core, how will we be sure it is
> maintained? What will test it?
>  2. Since it's in core, and C++ is a rapidly evolving language, what
> will the required C++ version be? What would our policy be on updating
> it?
>  3. How will we be sure about edges around language mismatches in C
> and C++? For instance, they have different rules regarding unions,
> which we make liberal use of.
>  4. C++ has many features and some are controversial. Will any be
> disallowed such as exceptions?
>
> There is one part of C++ specifically that I think could be pretty
> nice if we can figure out all the details: compile-time evaluation of
> the string hash function. This could make dealing with
> well-known/compile-time strings easier.
>

1. As for testing, we can implement either a second zend_test extension or
add the tests to the current one.
2. C++ is indeed a rapidly evolving language, I suggest starting with a
conservative approach by targeting a stable C++ version that balances
modern features with broad compatibility=E2=80=94C++17 or C++20 could be go=
od
candidates. As for updating the required version, we could establish a
policy where we review the C++ version every couple of years, aligning it
with broader trends in C++ adoption and compiler support across platforms.
This would help us avoid potential fragmentation or compatibility issues.
3. As long as we stick to the struct based approach, we should be fine
regarding the common edge cases. The idea is to keep the structs compatible
with C while supporting C++ features
4. To maintain a clean and consistent API, I suggest we disallow certain
C++ features like exceptions. Exceptions could introduce complexity and
unpredictability, especially when mixed with C's error handling mechanisms.


Overall, the goal is to use C++ to enhance the API without compromising the
stability and simplicity of the C core. We can focus on C++ features that
bring clear benefits, such as stronger type safety and cleaner
abstractions, while avoiding those that might introduce unnecessary
complexity.

Cheers,
Lanre

--00000000000081d39d061f7edd88
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 9:49=E2=80=AF=
AM Levi Morrison &lt;<a href=3D"mailto:levi.morrison@datadoghq.com">levi.mo=
rrison@datadoghq.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">On Sun, Aug 11, 2024 at 4:54=E2=80=AFPM Lanre &lt;<a hr=
ef=3D"mailto:lnearwaju@gmail.com" target=3D"_blank">lnearwaju@gmail.com</a>=
&gt; wrote:<br>
&gt;<br>
&gt; Hello,<br>
&gt;<br>
&gt; I=E2=80=99m considering adding some C++ enhancements to the Zend API. =
These changes would be encapsulated within `#ifdef __cplusplus` guards, so =
they wouldn=E2=80=99t interfere with the existing C implementation. The pri=
mary goal is to provide a nicer interface for extensions while maintaining =
compatibility with C.<br>
&gt;<br>
&gt; Key points:<br>
&gt; - **Struct-based Approach:** Everything will still use structs=E2=80=
=94no classes or non-public/non-static members.<br>
&gt; - **Isolation:** Any enhancements that can be isolated from the C impl=
ementation will be, and they will reside in a common `zend_api_cxx` header =
file.<br>
&gt; - **Proposed Enhancements:**<br>
&gt;=C2=A0 =C2=A0- Constructors and destructors, along with comparison oper=
ator overloads for `zval`.<br>
&gt;=C2=A0 =C2=A0- Constructor overloads for common `zval` initializations.=
<br>
&gt;=C2=A0 =C2=A0- Member methods for common `zval` operations.<br>
&gt;<br>
&gt; I=E2=80=99m happy to implement and maintain these changes. Since this =
doesn=E2=80=99t affect userland, do you think an RFC is necessary?<br>
&gt;<br>
&gt; Also, if anyone has suggestions or ideas for this C++ API, I=E2=80=99d=
 love to hear them.<br>
&gt;<br>
&gt; Cheers,<br>
&gt; Lanre<br>
<br>
I am not opposed, but there are some logistics questions:<br>
=C2=A01. Since it&#39;s for extensions and not core, how will we be sure it=
 is<br>
maintained? What will test it?<br>
=C2=A02. Since it&#39;s in core, and C++ is a rapidly evolving language, wh=
at<br>
will the required C++ version be? What would our policy be on updating<br>
it?<br>
=C2=A03. How will we be sure about edges around language mismatches in C<br=
>
and C++? For instance, they have different rules regarding unions,<br>
which we make liberal use of.<br>
=C2=A04. C++ has many features and some are controversial. Will any be<br>
disallowed such as exceptions?<br>
<br>
There is one part of C++ specifically that I think could be pretty<br>
nice if we can figure out all the details: compile-time evaluation of<br>
the string hash function. This could make dealing with<br>
well-known/compile-time strings easier.<br></blockquote><div><br></div><div=
>1. As for testing, we can implement either a second zend_test extension or=
 add the tests to the current one.</div><div>2. C++ is indeed a rapidly evo=
lving language, I suggest starting with a conservative approach by targetin=
g a stable C++ version that balances modern features with broad compatibili=
ty=E2=80=94C++17 or C++20 could be good candidates. As for updating the req=
uired version, we could establish a policy where we review the C++ version =
every couple of years, aligning it with broader trends in C++ adoption and =
compiler support across platforms. This would help us avoid potential fragm=
entation or compatibility issues.</div><div>3. As long as we stick to the s=
truct based approach, we should be fine regarding the common edge cases. Th=
e idea is to keep the structs compatible with C while supporting C++ featur=
es</div><div>4. To maintain a clean and consistent API, I suggest we disall=
ow certain C++ features like exceptions. Exceptions could introduce complex=
ity and unpredictability, especially when mixed with C&#39;s error handling=
 mechanisms.=C2=A0</div><div class=3D"gmail_quote"><br></div><br><div>Overa=
ll, the goal is to use C++ to enhance the API without compromising the stab=
ility and simplicity of the C core. We can focus on C++ features that bring=
 clear benefits, such as stronger type safety and cleaner abstractions, whi=
le avoiding those that might introduce unnecessary complexity.</div><div><b=
r></div>Cheers,<br><div>Lanre=C2=A0</div></div></div>

--00000000000081d39d061f7edd88--