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 “new __PHP_Incomplete_Class” on GitHub seems to show that it is mostly used 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
