rfc:php-namespace-in-core
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:php-namespace-in-core [2020/03/25 18:42] – brzuchal | rfc:php-namespace-in-core [2020/04/23 12:04] – Fill in W.I.P. section girgias | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== PHP RFC: PHP Namespace in core ====== | ====== PHP RFC: PHP Namespace in core ====== | ||
- | * Version: | + | * Version: |
* Date: 2020-03-25 | * Date: 2020-03-25 | ||
- | * Author: Michał Brzuchalski < | + | * Author: Michał Brzuchalski < |
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | Introduce | + | The PHP project has reserved the right to use the '' |
- | Introduction | + | This paves the way to reduce the usage of the global |
- | There is no concrete proposal on how to structure the namespaces and the only agreement | + | This is not a concrete proposal on how to structure the namespace or a proposal on re-aliasing classes to use the '' |
- | ===== Proposal | + | ===== Features which could benefit from the PHP namespace |
- | This RFC proposes to introduce PHP namespace for internal symbols by utilizing the reserved PHP namespace as the root for the symbols that are tightly coupled with PHP interpreter. | + | |
- | ==== New symbols tightly coupled to the core ==== | + | * The recently accepted [[rfc: |
- | We can either have `PhpToken` and `PhpAttribute` classes of which the second one is a future RFC proposal. | + | * The currently under discussion [[rfc: |
- | But with the PHP namespace, those names can be clean like `PHP\Token` and `PHP\Attribute`. | + | |
- | That kind of symbols | + | As these sort of symbols |
- | In hypothetically new RFC for small refactor like was done for [[https:// | + | ==== A small concrete example ==== |
- | for eg. `debug_backtrace()` which currently | + | Currently <php>debug_backtrace()</ |
- | ==== Renaming to fix some mistakes | + | ===== Proposal ===== |
- | Currently we do have `ReflectionType` and `ReflectionNamedType` but their purpose isn't exactly | + | New features or symbols which are tightly coupled |
- | + | ||
- | From type perspective, | + | |
- | Current `ReflectionType` functions as a type constraint in general therefore renaming it to `ReflectionTypeConstraint` could be a good way to resolve those issues and concerns. | + | |
- | + | ||
- | This RFC is not about renaming those classes but presents some mistakes taken in the past which cannot be changed between | + | |
- | + | ||
- | What this RFC opens is a way to make some cleanups and in this specific example opens a way to alias `ReflectionType` as a `PHP\ReflectionTypeConstraint` (technically in the opposite direction) so then `PHP\ReflectionType` can be used as a top reflector for all kind of types which can be introduced in a future, like enums generics etc. | + | |
- | Those kind of changes are not BC breaking changes allows to mark old classes as deprecated for a long period and use new class names in the meantime. | + | |
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
- | No incompatible changes | + | No backwards |
- | ===== Proposed PHP Version(s) ===== | + | ===== Proposed PHP Version ===== |
- | Next PHP 8.x. | + | PHP 8.0. |
- | ===== RFC Impact | + | ===== Concerns about inconsistent use ===== |
- | ==== To SAPIs ==== | + | Various symbols which are widely used are located in the global namespace, classes such as '' |
- | None. | + | |
- | ==== To Existing Extensions ==== | + | Although some of these fall into the category of being tightly tied to the engine and would land in the '' |
- | None. | + | |
- | ==== To Opcache | + | ===== Future scope ===== |
- | None. | + | Providing new core APIs building on new features introduces in PHP, such as: |
- | ==== New Constants ==== | + | * I/O API using exceptions instead of warnings in case of failure |
- | None. | + | * New data structures to replace SPL data structures, see Appendix for reasons why |
+ | Or revamping current ones: | ||
+ | | ||
+ | * Reflection, see Appendix for a use case | ||
+ | |||
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
- | As this is a language change, a 2/3 majority is required. | + | The vote is a straight Yes/No vote requiring a 2/3 majority to accept |
- | + | ||
- | The vote is a straight Yes/No vote for accepting | + | |
===== Patches and Tests ===== | ===== Patches and Tests ===== | ||
This RFC doesn' | This RFC doesn' | ||
+ | ===== Changelog ===== | ||
+ | 1.0.0: Initial version \\ | ||
+ | 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 ===== | ||
+ | ==== SPL Data Structures ==== | ||
+ | An infamous example is that <php> SplQueue extends SplDoublyLinkedList</ | ||
+ | |||
+ | Therefore, if a user decides to use these methods instead of the designated < | ||
+ | |||
+ | ==== Reflection ==== | ||
+ | Currently within the Reflection extension we have the following classes '' | ||
+ | |||
+ | From PHP's type system perspective, | ||
+ | |||
+ | Thus, in a revamped Reflection extension one could imagine a more accurate '' |
rfc/php-namespace-in-core.txt · Last modified: 2020/06/04 11:51 by brzuchal