This is an old revision of the document!

PHP RFC: PHP Namespace Policy


In light of the ever-increasing number of userland-accessible classes being provided by the PHP-SRC, and the ever-increasing amount of symbols within the root namespace, this RFC proposes that internals withdraws its policy of placing everything within the root namespace, and instead adopts the policy of taking ownership of the \php namespace and everything beneath it, for the purposes of offering a way for current and future RFC authors to properly namespace any new classes which they add.

By design this RFC does NOT propose moving anything existing into the \PHP namespace at this time, nor does it REQUIRE future development uses it, only that the policy is set that it is the preferred mechanism for future development where suitable to do so.

Namespace Claims

This RFC would establish the protocol for a registry, upon which internals and core extension authors can, as part of their RFC, petition voters for a child namespace with which to place their additions, subject to the vote being passed. Laying claim to a child namespace of \PHP would be part of the main feature vote.

Realistically this would be no different than the current mechanism of submitting a technical RFC that had class names included in it.

Requests to add additional namespaces for purposes such as aliasing existing classes as a means of migration, would be performed by a standard 2/3rds vote, multiple such classes may be included in a single vote if the community feels it appropriate.

Once approved, a namespace that is a child of \PHP will remain exclusively for the originally assigned purpose, even if the associated code is moved out of core, unless a 2/3rds vote is held to withdraw that namespace, at which point it could be re-used, but this seems extremely unlikely to be used.

Namespace Structure

The top-level \PHP namespace itself would be exclusively used as a container for other namespaces, and itself would not contain any classes.

The \PHP\Engine namespace would be reserved for namespaces and classes which directly interface with the operation of the engine, e.g. future annotations relating to the operation of JIT.

There should be no restriction upon depth, although common sense should be used.


  • \PHP (must be empty except for other namespaces)
  • \PHP\Engine (reserved for things effecting the engine itself such as annotations or ErrorLevel::WARNING)

Mandatory Implementation Details

This RFC proposes that the contents of the \PHP namespace are exclusively class-like (class, interface, trait) or namespaces and that constants, standalone functions and any other data is strictly prohibited. This would be because support for function type autoloading seems unlikely to emerge and using classes provides better opportunity for autoloaded polyfills.

Constants MUST be declared as class constants (or enums) as is currently demonstrated by ZipArchive. Functions MUST be declared as static member functions.

Proposed PHP Version(s)

PHP 8.0


Yes / No

“Should RFC authors be permitted to utilise a sub-namespace of \PHP to contain their features' userland accessible classes, traits, interfaces etc”

Prior Art

rfc/php_namespace_policy.1590180483.txt.gz · Last modified: 2020/05/22 20:48 by marandall