Req #71037 [Csd->Sus]: Interfaces for Reflection API

From: Date: Sat, 26 Mar 2016 21:41:53 +0000
Subject: Req #71037 [Csd->Sus]: Interfaces for Reflection API
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-200121@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=71037&edit=1 ID: 71037 Updated by: krakjoe@php.net Reported by: andreas at dqxtech dot net Summary: Interfaces for Reflection API -Status: Closed +Status: Suspended Type: Feature/Change Request Package: Reflection related Operating System: Linux PHP Version: 7.0.0 Assigned To: krakjoe Block user comment: N Private report: N Previous Comments: ------------------------------------------------------------------------ [2016-03-26 21:36:06] krakjoe@php.net For this kind of change, an RFC is required. Please see: https://wiki.php.net/rfc/howto ------------------------------------------------------------------------ [2015-12-06 07:53:15] andreas at dqxtech dot net 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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=71037 -- Edit this bug report at https://bugs.php.net/bug.php?id=71037&edit=1

« previous php.bugs (#200121) next »