| Both sides previous revisionPrevious revision | Next revisionBoth sides next revision |
| rfc:php-namespace-in-core [2020/04/23 11:10] – girgias | rfc:php-namespace-in-core [2020/04/23 11:17] – Major rewrite girgias |
|---|
| |
| ==== 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 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 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 ===== |
| ===== Proposed PHP Version ===== | ===== Proposed PHP Version ===== |
| PHP 8.0. | PHP 8.0. |
| | |
| | ===== Open Issues ===== |
| | W.I.P. SPL Interfaces such as Countable, ArrayAccess, etc. |
| |
| ===== Future scope ===== | ===== Future scope ===== |
| 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. |