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.

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....

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.

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.

For this kind of change, an RFC is required.

Please see: https://wiki.php.net/rfc/howto