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