| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| rfc:php-namespace-in-core [2020/04/03 14:04] – Major rewrite girgias | rfc:php-namespace-in-core [2020/04/15 20:37] – Use must instead of may, Changelog section, small nits girgias |
|---|
| ====== PHP RFC: PHP Namespace in core ====== | ====== PHP RFC: PHP Namespace in core ====== |
| * Version: 0.9 | * Version: 1.1.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: Draft | * Status: Under Discussion |
| * First Published at: http://wiki.php.net/rfc/php-namespace-in-core | * First Published at: http://wiki.php.net/rfc/php-namespace-in-core |
| |
| ===== Introduction ===== | ===== Introduction ===== |
| 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. | 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 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. |
| |
| 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] | 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 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. | |
| |
| ===== Features which could benefit from the PHP namespace ===== | ===== Features which could benefit from the PHP namespace ===== |
| * The currently under discussion [[rfc:attributes_v2|PHP RFC: Attributes v2]] could use the ''\PHP'' namespace for engine/internal related attributes. | * The currently under discussion [[rfc:attributes_v2|PHP RFC: Attributes v2]] could use the ''\PHP'' namespace for engine/internal related attributes. |
| |
| 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 the situation where symbols under the ''\PHP'' namespace are always available in PHP. | 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 are 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. |
| |
| ==== A small toy-example ==== | ==== A small toy-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 would signal 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 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. |
| |
| ===== A chance to clean up poor design/naming decisions ===== | ===== A chance to clean up poor design/naming decisions ===== |
| Currently within the Reflection extension we have the following classes ''ReflectionType'' and ''ReflectionNamedType'' however their purpose isn't exacty to present a type. | Currently within the Reflection extension we have the following classes ''ReflectionType'' and ''ReflectionNamedType'' however their purpose isn't exactly to present a type. |
| |
| 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. |
| 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. | 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. |
| |
| 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 use case of the proposal is a redesign once, life with it's imperfection forever. We still believe this may be a valid use case. | 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 ===== |
| Allow tightly coupled internal/engine symbols with the PHP interpreter to use the ''\PHP'' namespace. | New features or symbols which are tightly coupled to the internals/engine of the PHP interpreter must use the ''\PHP'' namespace starting from PHP 8. |
| |
| ===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== |
| No backwards incompatible changes as we would only introduce new classes under a the ''\PHP'' namespace. | No backwards incompatible changes as only new classes/symbols would be introduces under the ''\PHP'' namespace. |
| |
| ===== Proposed PHP Version ===== | ===== Proposed PHP Version ===== |
| Next PHP 8.0. | PHP 8.0. |
| | |
| ===== RFC Impact ===== | |
| ==== To SAPIs ==== | |
| None. | |
| | |
| ==== To Existing Extensions ==== | |
| None. | |
| | |
| ==== To Opcache ==== | |
| None. | |
| | |
| ==== New Constants ==== | |
| None. | |
| |
| ===== 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. |
| |
| ===== Patches and Tests ===== | ===== Patches and Tests ===== |
| This RFC doesn't provide any changes. | This RFC doesn't provide any changes. |
| | |
| | ===== Changelog ===== |
| | 1.0.0: Initial version \\ |
| | 1.1.0: New features must use the PHP engine, before this was merely a suggestion \\ |
| | |
| |