Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128402
Precedence: list
MIME-Version: 1.0
Date: Wed, 6 Aug 2025 10:32:34 +0200
Message-ID: <CAMU7ir+Ax0e1cT5O2J2LdpUXR493nf+jdyK2Q3Dq8X7GV-DKhQ@mail.gmail.com>
Subject: [PHP-DEV] [DISCUSSION] Deprecating userland creation and cloning of __PHP_Incomplete_Class
To: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: alex.daubois+php@gmail.com (Alexandre Daubois)

Hello Internals,

I would like to gather feedback on the proposal to deprecate userland
creation and cloning of __PHP_Incomplete_Class objects.

Here are the reasons I believe this deprecation would be beneficial:

- __PHP_Incomplete_Class is intended to be an internal mechanism for
handling incomplete object unserialization, not for direct userland
manipulation;
- This change would align with PHP's general direction of preventing
misuse of internal classes;
- Classes like Generator already prevent userland instantiation,
making this change consistent with existing patterns;
- No added-value on using this class in userland, stdClass does
already the job if one wants to manipulate "incomplete" classes.
Having stdClass and __PHP_Incomplete_Class could be misleading;
- Prior to PHP 7.2, is_object() on such object returned false, showing
how this is some kind of special case.

The proposed deprecation would affect:

- Direct instantiation: `new __PHP_Incomplete_Class()`
- Cloning operations: `clone $incompleteClassInstance`

Regarding the impact this would have, a search for =E2=80=9Cnew
__PHP_Incomplete_Class=E2=80=9D on GitHub seems to show that it is mostly u=
sed
in Rector rules targeting PHP 7.2. It therefore seems to me to be
minimal and worthwhile from the point of view of the robustness of the
language. Adding "language: PHP" shows even less results, apart from
test files from php-src.

If this proposal receives interest, I would be happy to implement the
deprecation warnings in the engine and prepare an RFC if required.
Unless the change is actually uncontroversial? It seems to me, but I'm
looking forward to your thoughts and feedback.

Best,
Alexandre Daubois