Req #71037 [Csd->Sus]: Interfaces for Reflection API
| From: | krakjoe@php.net | 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