PHP-SRC provides an ever-increasing number of userland-accessible classes. The recent addition of Attributes is very likely to result in even more in the future. Every new global class, however, creates a potential namespace collision with existing user-space code and thus a potential for backward compatibility breaks.
This RFC proposes to:
This RFC does NOT propose moving any existing code into the \PHP namespace at this time. That may be done by future RFCs if desired, under their own votes. This is a “policy document” only.
A page will be established on the PHP Wiki (this site) to index all explicitly specified component namespaces for both \PHP and \Ext.
For \PHP, classes may be added or removed only via RFC. That may be an RFC to add a feature that uses the namespace or it may be an RFC to rename an existing class to conform to this RFC.
A \PHP component namespace is “claimed” by the RFC that first uses it. Once claimed, that component namespace may only be used only by that RFC or future RFCs that extend that one in a natural way. For example, once it's established that \PHP\Attribute\ is the namespace for attributes, additional attribute classes may be defined there but no non-attribute-related classes may be. Once the RFC is approved, the namespace should be added to the index.
An \Ext component namespace is “claimed” in one of three ways:
The following heuristics are intended to guide the review of future RFCs by providing a consistent pattern for naming. They are by nature not hard and precise rules, but future RFCs SHOULD follow them as closely as possible.
Examples of existing classes or components listed below are for explanatory and demonstration purposes only. This RFC does not propose to rename them here. Future RFCs may do so if desired, following the process outlined below.
Classes or interfaces that impact the type system in ways that affect runtime behavior
Classes or interfaces that extend a type the previous group
Classes that are part of an extension, disableable or not.
Cases where it is expected that the number of closely related classes is or is likely to become large
Cases not covered above:
This RFC makes no change to existing classes, regardless of where they are defined. Future RFCs may be proposed to migrate existing classes to a component namespace within \PHP or \Ext as appropriate, and put to a vote on their own merits. Such RFCs must:
1. Clearly specify what classes or interfaces will migrate to a component namespace, including whether or not their name will be changing in the process. 2. Include an alias, subclass, or other backward compatibility shim to ensure existing userland code remains working without change.
Removal of the older, un-namespaced symbols must happen in a separate RFC, and MUST happen no earlier than one full release cycle after that introduction of the namespaced symbol. That is, a rename introduced in PHP 8.2 is not eligible to have its old name removed until at least 10.0.
PHP 8.0 (doesn't really have an impact until 8.1, however)
Voting opened 2020-07-26 and closes 2020-08-09.
Yes / No vote, requiring 2/3 to pass.
“Should PHP adopt these guidelines for future RFC authors to guide when and how to use the \PHP and \Ext namespaces for userland-accessible classes and similar?”
https://wiki.php.net/rfc/namespaces-in-core (withdrawn)