This is an old revision of the document!
PHP RFC: PHP Namespace in core
Introduce PHP namespace to core symbols which cannot be unbundled and are strictly language/parser/interpreter related as a way to fix some mistakes, clean up global namespace and to avoid collisions with user-defined symbols.
Introduction of PHP namespace also as a way for gradual migration over renamed and marked as deprecated symbols reducing breaking changes.
There is no concrete proposal on how to structure the namespaces and the only agreement is that core classes which are tightly coupled with the core can start using `PHP` namespace for type prefixes.
This RFC proposes to introduce PHP namespace for internal symbols by utilizing the reserved PHP namespace as the root for the symbols that are tightly coupled with PHP interpreter.
New symbols tightly coupled to the core
We can either have `PhpToken` and `PhpAttribute` classes of which the second one is a future RFC proposal. But with the PHP namespace, those names can be clean like `PHP\Token` and `PHP\Attribute`.
That kind of symbols belongs only to the core. Therefore they will newer be unbundled and moved to PECL.
In hypothetically new RFC for small refactor like was done for Object-based token_get_all() alternative for eg. `debug_backtrace()` which currently produces an array of arrays and introduction of a sort of `Frame` would be proposed for object-based alternative then `PHP` namespace is the natural owner of for eg. `PHP\Frame` without that we may cause some BC breaks in userland which is not likely to happen with `PHP` namespace prefix.
Renaming to fix some mistakes
Currently we do have `ReflectionType` and `ReflectionNamedType` but their purpose isn't exactly to present a type.
From type perspective, a class is a type therefore why `ReflectionClass` doesn't in its hierarchy extend `ReflectionType`? Current `ReflectionType` functions as a type constraint in general therefore renaming it to `ReflectionTypeConstraint` could be a good way to resolve those issues and concerns.
This RFC is not about renaming those classes but presents some mistakes taken in the past which cannot be changed between the PHP releases without a huge BC break.
What this RFC opens is a way to make some cleanups and in this specific example opens a way to alias `ReflectionType` as a `PHP\ReflectionTypeConstraint` (technically in the opposite direction) so then `PHP\ReflectionType` can be used as a top reflector for all kind of types which can be introduced in a future, like enums generics etc. Those kind of changes are not BC breaking changes allows to mark old classes as deprecated for a long period and use new class names in the meantime.
Backward Incompatible Changes
No incompatible changes
Proposed PHP Version(s)
Next PHP 8.x.
To Existing Extensions
Proposed Voting Choices
As this is a language change, a 2/3 majority is required.
The vote is a straight Yes/No vote for accepting the RFC.
Patches and Tests
This RFC doesn't provide any changes.