Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124876
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 11 Aug 2024 15:54:07 -0600
Message-ID: <CAM7F2-8wfzQd_69xx+BkVYG_i0XDse9L-u7io6ys5FZn0Hvz4g@mail.gmail.com>
Subject: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000bdfe7061f6f6b67"
From: lnearwaju@gmail.com (Lanre)

--0000000000000bdfe7061f6f6b67
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

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 primary goal is to
provide a nicer interface for extensions while maintaining compatibility
with C.

Key points:
- **Struct-based Approach:** Everything will still use structs=E2=80=94no c=
lasses
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 doesn=
=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

--0000000000000bdfe7061f6f6b67
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,<br><br>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 exi=
sting C implementation. The primary goal is to provide a nicer interface fo=
r extensions while maintaining compatibility with C. <br><br>Key points:<br=
>- **Struct-based Approach:** Everything will still use structs=E2=80=94no =
classes or non-public/non-static members.<br>- **Isolation:** Any enhanceme=
nts that can be isolated from the C implementation will be, and they will r=
eside in a common `zend_api_cxx` header file.<br>- **Proposed Enhancements:=
** =C2=A0<br>=C2=A0 - Constructors and destructors, along with comparison o=
perator overloads for `zval`.<br>=C2=A0 - Constructor overloads for common =
`zval` initializations.<br>=C2=A0 - Member methods for common `zval` operat=
ions.<br><br>I=E2=80=99m happy to implement and maintain these changes. Sin=
ce this doesn=E2=80=99t affect userland, do you think an RFC is necessary?<=
/div><div><br></div><div>Also, if anyone has suggestions or ideas for this =
C++ API, I=E2=80=99d love to hear them.<br><br>Cheers, =C2=A0<br>Lanre<br><=
/div></div>

--0000000000000bdfe7061f6f6b67--