rfc:php-namespace-in-core

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:php-namespace-in-core [2020/04/23 11:10]
girgias
rfc:php-namespace-in-core [2020/06/04 11:51] (current)
brzuchal closed voting
Line 1: Line 1:
 ====== PHP RFC: PHP Namespace in core ====== ====== PHP RFC: PHP Namespace in core ======
-  * Version: 1.1.0+  * Version: 1.2.0
   * Date: 2020-03-25   * Date: 2020-03-25
   * Author: Michał Brzuchalski <​brzuchal@php.net>,​ George Peter Banyard <​girgias@php.net>​   * Author: Michał Brzuchalski <​brzuchal@php.net>,​ George Peter Banyard <​girgias@php.net>​
-  * Status: ​Under Discussion+  * Status: ​Declined
   * First Published at: http://​wiki.php.net/​rfc/​php-namespace-in-core   * First Published at: http://​wiki.php.net/​rfc/​php-namespace-in-core
  
Line 9: Line 9:
 The PHP project has reserved the right to use the ''​\PHP''​ namespace but has never acted upon starting to use it. We therefore propose that core symbols which cannot be unbundled such as those related to the language/​parser/​interpreter must use ''​\PHP''​ namespace. The PHP project has reserved the right to use the ''​\PHP''​ namespace but has never acted upon starting to use it. We therefore propose that core symbols which cannot be unbundled such as those related to the language/​parser/​interpreter must use ''​\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.+This paves the way to reduce the usage of the global namespace as "​PHP"'​s namespace.
  
-This is not a concrete proposal on how to structure the namespace or a proposal on realiasing ​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 must start using the ''​\PHP''​ namespace, e.g. for type prefixes.+This is not a concrete proposal on how to structure the namespace or a proposal on re-aliasing ​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 must start using the ''​\PHP''​ namespace, e.g. for type prefixes.
  
 ===== Features which could benefit from the PHP namespace ===== ===== Features which could benefit from the PHP namespace =====
Line 21: Line 21:
  
 ==== A small concrete example ==== ==== A small concrete example ====
-Currently <​php>​debug_backtrace()</​php>​ produces ​and array of arrays. An object oriented API could introduce the <​php>​Frame</​php>​ 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+Currently <​php>​debug_backtrace()</​php>​ produces ​an array of arrays. An object oriented API could introduce the <​php>​Frame</​php>​ class to hold details about each frame in the backtrace. As this would be an internal API using the ''​\PHP''​ namespace 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 ===== +
- +
- +
-This RFC could allow us to redesign, with the benefit of hindsight, some of the core APIs provided by PHP. +
- +
-Although some of these concerns may be fixed with the introduction of the [[https://​github.com/​nikic/​php-rfcs/​blob/​language-evolution/​rfcs/​0000-language-evolution.md|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 ===== ===== Proposal =====
Line 38: Line 31:
 ===== Proposed PHP Version ===== ===== Proposed PHP Version =====
 PHP 8.0. PHP 8.0.
 +
 +===== Concerns about inconsistent use =====
 +Various symbols which are widely used are located in the global namespace, classes such as ''​Closure''​ or ''​Generator''​ and interfaces such as ''​Countable'',​ ''​ArrayAccess'',​ and many others.
 +
 +Although some of these fall into the category of being tightly tied to the engine and would land in the ''​\PHP''​ namespace under this proposal if newly introduced. We consider the long term advantage of using the namespace and the benefits it can provide as a an acceptable trade-off.
  
 ===== Future scope ===== ===== Future scope =====
Line 51: Line 49:
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
 The vote is a straight Yes/No vote requiring a 2/3 majority to accept the RFC. The vote is a straight Yes/No vote requiring a 2/3 majority to accept the RFC.
 +
 +===== Vote =====
 +Voting started on 2020-05-22 and will end on 2020-06-04 at 6:00 UTC.
 +<doodle title="​Accept PHP namespace in core RFC?" auth="​brzuchal"​ voteType="​single"​ closed="​true">​
 +   * Yes
 +   * No
 +</​doodle>​
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
Line 58: Line 63:
 1.0.0: Initial version \\ 1.0.0: Initial version \\
 1.1.0: New features must use the PHP engine, before this was merely a suggestion \\ 1.1.0: New features must use the PHP engine, before this was merely a suggestion \\
 +1.2.0: Major rewrite, addressing concerns about inconsistent usage \\
  
 ===== Appendix ===== ===== Appendix =====
Line 70: Line 76:
 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. 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.
  
 +Thus, in a revamped Reflection extension one could imagine a more accurate ''​PHP\ReflectionTypeConstraint''​ to represent the current ''​ReflectionType''​ and introduce a new top reflector ''​PHP\ReflectionType''​ for all types current, and future. E.g Enums, Generics, etc.
rfc/php-namespace-in-core.1587640226.txt.gz · Last modified: 2020/04/23 11:10 by girgias