Re: [RFC][VOTE] Allow abstract function override
| From: | Marco Pivetta | Date: | Tue, 28 Mar 2017 16:41:13 +0000 |
| Subject: | Re: [RFC][VOTE] Allow abstract function override | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-98658@lists.php.net to get a copy of this message | ||
Hey Folks,
Sorry, my mistake on detecting the BC break. I had a misconception about
how
ReflectionMethod#getDeclaringClass() works. I thought that the
declaring class was the declaring abstraction, but it's actually always
pointing to the most concrete implementation in the inheritance.
See https://3v4l.org/t7PiL
Code, for reference:
<?php
class Thing {}
interface Foo {
public function bar($baz) : Thing;
}
interface Bar extends Foo {
public function bar($baz) : Thing;
}
final class Baz implements Bar
{
public function bar($baz) : Thing
{
return new Thing;
}
}
var_dump((new
ReflectionClass(Foo::class))->getMethod('bar')->getDeclaringClass()->getName());
// expected Foo, it actually is Foo
var_dump((new
ReflectionClass(Bar::class))->getMethod('bar')->getDeclaringClass()->getName());
// expected Foo, got Bar (my assumption was wrong)
var_dump((new
ReflectionClass(Baz::class))->getMethod('bar')->getDeclaringClass()->getName());
// expected Foo, got Baz (my assumption was wrong)
This is my mistake, as I didn't verify my assumption on code before
reporting the BC break. Sorry again - changing my vote to yes, as the
discussed covariance/contravariance changes make sense for interfaces as
well.
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/