This is an old revision of the document!
PHP RFC: PHP Namespace in core
- Version: 0.9
- Date: 2020-03-25
- Author: Michał Brzuchalski brzuchal@php.net, George Peter Banyard girgias@php.net
- Status: Draft
- First Published at: http://wiki.php.net/rfc/php-namespace-in-core
Introduction
The PHP project has reserved the right to use the \PHP
namespace but has never acted upon starting to use it. We therefore suggest that core symbols which cannot be unbundled such as those related to the language/parser/interpreter may start using the \PHP
namespace.
This would provide a way to reduce the usage of the global namespace as “PHP”'s namespace and also provide a way to fix some fundamental misnaming.
Introduction of PHP namespace also as a way for gradual migration over renamed and marked as deprecated symbols reducing breaking changes. [Girgias Note: I'm not sure this sentence makes sense]
This is not a concrete proposal on how to structure the namespace or a proposal on realising classes to use the \PHP
namespace. This is only an agreement that core classes or newly introduced symbols which are tightly coupled to the PHP engine may start using the \PHP
namespace, e.g. for type prefixes.
Features which could benefit from the PHP namespace
- The recently accepted PHP RFC: Object-based token_get_all() alternative uses the
\PhpToken
class but under this proposal it could be\PHP\PhpToken
- The currently under discussion PHP RFC: Attributes v2 could use the
\PHP
namespace for engine/internal related attributes.
As these sort of symbols are tied to the engine there is no risk that they will get unbundled from PHP core and moved to PECL. We note this as we aware that if a non core extension would use the \PHP
namespace and gets unbundled and moved to PECL we would find ourselves in a situation where symbols under the \PHP
namespace are not always available in PHP.
A small toy-example
Currently debug_backtrace()
produces and array of arrays. An object oriented API could introduce the Frame
class to hold details about each frame in the backtrace. As this would be an internal API using the \PHP
namespace this signals clear ownership and possibly limit the BC breaks for users which don't use the namespace feature of PHP.
A chance to clean up poor design/naming decisions
Currently within the Reflection extension we have the following classes ReflectionType
and ReflectionNamedType
however their purpose isn't exacty to present a type.
From PHP's type system perspective, a class is a type. Therefore, ReflectionClass
not extending from ReflectionType
could be seen as questionable. Thus the ReflectionType
class acts more as a type constraint and renaming it to ReflectionTypeConstraint
may be a good way to clarify it's concern.
This RFC could allow us to redesign, with the benefit of hindsight, some of the core APIs provided by PHP.
Continuing from the previous example we could alias ReflectionType
to the more accurate PHP\ReflectionTypeConstraint
class name, and possibly in the future introduce PHP\ReflectionType
as the top reflector for all kinds of types which may be introduced in the future, e.g. Enums, Generics, etc.
Another infamous example would be some of the data structures provides by the SPL extension. Indeed as SplQueue extends SplDoublyLinkedList
this means that SplQueue
inherits the push()
and pop()
methods from SplDoublyLinkedList
meaning that if you decide to use these functions instead of the designated enqueue()
and dequeue()
methods you get something which behave like a stack instead of a queue.
Although some of these concerns may be fixed with the introduction of the Language evolution RFC as this aspect of the proposal is a redesign once, live with it's imperfection forever. We still believe this may have some valid use cases which are not easily achieved with the fore-mentioned RFC.
Proposal
Allow tightly coupled internal/engine symbols with the PHP interpreter to use the \PHP
namespace.
Backward Incompatible Changes
No backwards incompatible changes as we would only introduce new classes under a the \PHP
namespace.
Proposed PHP Version
Next PHP 8.0.
Proposed Voting Choices
The vote is a straight Yes/No vote requiring a 2/3 majority to accept the RFC.
Patches and Tests
This RFC doesn't provide any changes.