| 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 12:30] – Changed status brzuchal |
|---|
| * 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 |
| |
| * 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 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 ===== |
| 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 ===== |
| ===== Proposed PHP Version ===== | ===== Proposed PHP Version ===== |
| Next PHP 8.0. | Next PHP 8.0. |
| |
| ===== RFC Impact ===== | |
| ==== To SAPIs ==== | |
| None. | |
| |
| ==== To Existing Extensions ==== | |
| None. | |
| |
| ==== To Opcache ==== | |
| None. | |
| |
| ==== New Constants ==== | |
| None. | |
| |
| ===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== |