Differences

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

--- rfc:php-namespace-in-core [2020/03/25 18:42] – brzuchal
+++ rfc:php-namespace-in-core [2020/04/06 21:16] – Removed Impact section as this is a process RFC, small tweaks girgias
@@ Line 2: / Line 2: @@
   * Version: 0.9
   * Date: 2020-03-25
-  * Author: Michał Brzuchalski <brzuchal@php.net>
+  * Author: Michał Brzuchalski <brzuchal@php.net>, George Peter Banyard <girgias@php.net>
   * Status: Draft
   * First Published at: http://wiki.php.net/rfc/php-namespace-in-core
 ===== Introduction =====
-Introduce PHP namespace to core symbols which cannot be unbundled and are strictly language/parser/interpreter related as a way to fix some mistakes, clean up global namespace and to avoid collisions with user-defined symbols.
+The PHP project has reserved the right to use the ''\PHP'' namespace but has never acted upon starting to use it. We therefore suggest that core symbols which cannot be unbundled such as those related to the language/parser/interpreter may start using the ''\PHP'' namespace.
-Introduction of PHP namespace also as a way for gradual migration over renamed and marked as deprecated symbols reducing breaking changes.
+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.
-There is no concrete proposal on how to structure the namespaces and the only agreement is that core classes which are tightly coupled with the core can start using `PHP` namespace for type prefixes.
+Introduction of PHP namespace also as a way for gradual migration over renamed and marked as deprecated symbols reducing breaking changes. [Girgias Note: I'm not sure this sentence makes sense]
-===== Proposal =====
+This is not a concrete proposal on how to structure the namespace or a proposal on realising 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 may start using the ''\PHP'' namespace, e.g. for type prefixes.
-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 ====
+===== Features which could benefit from the PHP namespace =====
-We can either have `PhpToken` and `PhpAttribute` classes of which the second one is a future RFC proposal.
-But with the PHP namespace, those names can be clean like `PHP\Token` and `PHP\Attribute`.
-That kind of symbols belongs only to the core. Therefore they will newer be unbundled and moved to PECL.
+  * The recently accepted [[rfc:token_as_object|PHP RFC: Object-based token_get_all() alternative]] uses the <php>\PhpToken</php> class but under this proposal it could be <php>\PHP\PhpToken</php>
+  * The currently under discussion [[rfc:attributes_v2|PHP RFC: Attributes v2]] could use the ''\PHP'' namespace for engine/internal related attributes.
-In hypothetically new RFC for small refactor like was done for [[https://wiki.php.net/rfc/token_as_object|Object-based token_get_all() alternative]]
+As these sort of symbols are tied to the engine there is no risk that they will get unbundled from PHP core and moved to PECL. We note this as we aware that if a non core extension would use the ''\PHP'' namespace and gets unbundled and moved to PECL we would find ourselves in a situation where symbols under the ''\PHP'' namespace are not always available in PHP.
-for eg. `debug_backtrace()` which currently produces an array of arrays and introduction of a sort of `Frame` would be proposed for object-based alternative then `PHP` namespace is the natural owner of for eg. `PHP\Frame` without that we may cause some BC breaks in userland which is not likely to happen with `PHP` namespace prefix.
-==== Renaming to fix some mistakes ====
+==== A small toy-example ====
-Currently we do have `ReflectionType` and `ReflectionNamedType` but their purpose isn't exactly to present a type.
+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.
-From type perspective, a class is a type. Therefore `ReflectionClass` not extending `ReflectionType` could be questionable.
+===== A chance to clean up poor design/naming decisions =====
-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.
+Currently within the Reflection extension we have the following classes ''ReflectionType'' and ''ReflectionNamedType'' however their purpose isn't exacty to present a type.
-This RFC is not about renaming those classes but presents some mistakes taken in the past which cannot be changed between the PHP releases without a huge BC break.
+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.
-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.
+This RFC could allow us to redesign, with the benefit of hindsight, some of the core APIs provided by PHP.
-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 =====
+Continuing from the previous example we could alias ''ReflectionType'' to the more accurate ''PHP\ReflectionTypeConstraint'' class name, and possibly in the future introduce ''PHP\ReflectionType'' as the top reflector for all kinds of types which may be introduced in the future, e.g. Enums, Generics, etc.
-No incompatible changes
-===== Proposed PHP Version(s) =====
+Another infamous example would be some of the data structures provides by the SPL extension. Indeed as <php> SplQueue extends SplDoublyLinkedList</php> this means that <php>SplQueue</php> inherits the <php>push()</php> and <php>pop()</php> methods from <php>SplDoublyLinkedList</php> meaning that if you decide to use these functions instead of the designated <php>enqueue()</php> and <php>dequeue()</php> methods you get something which behave like a stack instead of a queue.
-Next PHP 8.x.
-===== RFC Impact =====
+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.
-==== To SAPIs ====
-None.
+===== Proposal =====
+Allow tightly coupled internal/engine symbols with the PHP interpreter to use the ''\PHP'' namespace.
-==== To Existing Extensions ====
+===== Backward Incompatible Changes =====
-None.
+No backwards incompatible changes as we would only introduce new classes under a the ''\PHP'' namespace.
-==== To Opcache ====
-None.
-==== New Constants ====
+===== Proposed PHP Version =====
-None.
+Next PHP 8.0.
 ===== Proposed Voting Choices =====
-As this is a language change, a 2/3 majority is required.
-The vote is a straight Yes/No vote for accepting the RFC.
+The vote is a straight Yes/No vote requiring a 2/3 majority to accept the RFC.
 ===== Patches and Tests =====
 This RFC doesn't provide any changes.

Differences

Page Tools