Req #71037 [Com]: Interfaces for Reflection API

Edit report at https://bugs.php.net/bug.php?id=71037&edit=1 ID: 71037 Comment by: andreas at dqxtech dot net Reported by: andreas at dqxtech dot net Summary: Interfaces for Reflection API Status: Open Type: Feature/Change Request Package: Reflection related Operating System: Linux PHP Version: 7.0.0 Block user comment: N Private report: N New Comment: Btw, one reason why such libraries exist in the first place: https://bugs.php.net/bug.php?id=70761 Request #70761 Fatal error if missing parent class - create "stub" class instead Typical scenario: A library contains a class that is autoloadable, but its parent class or implemented interface is not - because it belongs to an optional dependency. Then we have some kind of discovery mechanism, which wants to look at the class for whichever purpose. Doing this with native reflection will trigger autoload and include, which then causes fatal due to the missing parent class or interface. The idea there was to fatal when the class is actually used, not when the file is included. Previous Comments: ------------------------------------------------------------------------ [2015-12-06 07:47:12] andreas at dqxtech dot net Ok.. only this won't work when calling existing 3rd party functions / methods that expect a \ReflectionSomething as a parameter. An alternative would be to interface only a stable subset of the reflection functionality. The part that makes sense to implement differently. ------------------------------------------------------------------------ [2015-12-05 21:41:31] danack@php.net You almost certainly don't want this. Having interface in PHP core is fine for small well defined constructs. However it becomes very very painful when the interfaces are either only vaguely defined or very large, as each change to the definition of the interface would be a backwards compatibility breaking change. The Reflection classes are both large and ill-defined. Having the internal classes implement an interface would either be very annoying for users of this interface, or for PHP core devs who would now have to wait until major/minor releases to change the definitions of the interfaces. Alternatively, you can achieve what you want to achieve by simply defining the appropriate interface in UserLand, and then making a proxy implementation to the Reflection api. e.g. interface ReflectionClassInterface { public function getConstant(string $name); public function getConstants() : array; public function getConstructor() : \ReflectionMethod; //all the other methods. } class ReflectionClassCore implments ReflectionClassInterface { private $reflectionClass; public function __construct(\ReflectionClass $reflectionClass) { $this->reflectionClass = $reflectionClass; } public function getConstant(string $name) { return $this->reflectionClass->getConstant($name); } public function getConstants() : array { return $this->reflectionClass->getConstants(); } public function getConstructor() : \ReflectionMethod { return $this->reflectionClass->getConstructor(); } //...and so on. } This would take you less than an hour to do, which is significantly less time that just the discussion on the internals list would take. That interface wouldn't break when the internal classes have methods added or altered, and probably has other benefits as well e.g. being able to improve the reflection api without waiting for PHP core to change. TL:DR interfaces are great, but not right here.... ------------------------------------------------------------------------ [2015-12-05 09:00:39] andreas at dqxtech dot net Of course I don't really care if it is IReflectionFunction or ReflectionFunctionInterface. But the latter pattern would give us ReflectionInterface vs ReflectionInterfaceInterface, which seems bad. ------------------------------------------------------------------------ [2015-12-05 08:58:53] andreas at dqxtech dot net Description: ------------ The native Reflection API should provide interfaces like \IReflectionClass, which can then be used for type hinting. This way, libraries such as https://github.com/Roave/BetterReflection or https://github.com/Andrewsville/PHP-Token-Reflection don't need to extend or wrap core reflection classes, but can instead implement the interface. One problem with this is that some libraries might only want to implement some of the methods of e.g. \ReflectionFunction, but not all of them. To allow this, there would need to be partial interfaces - which could be a longer discussion. I think for a start it would be sufficient to just have one interface for each of the already existing classes of the Reflection API. More interfaces could be added in the future. Test script: --------------- class C {..} function foo(\IReflectionClass $reflectionClass) {..} foo(new \ReflectionClass('C')); class MyReflectionClass implements \IReflectionClass { .. } foo(new MyReflectionClass('C')); ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=71037&edit=1