Since the call A::foo() is completely defined and that no "fall back"
occurs, I guess "A" is more expected as a result of this script.
Your patch will return B. I discussed this matter quite heavily on
#php.pecl and the expectations were also that "A" should get returned here.
I've taken a look at this patch and for the most part I agree that your code SHOULD return 'A'. However, one thing that I think is very important is that you are able to somehow pass-thru who the caller is when dealing with inheritance.
For instance:
<?php
class Foo
{
const TEST_CONST = 'foo';
public function test()
{
return static::TEST_CONST;
}
}
class Bar extends Foo
{
const TEST_CONST = 'bar';
}
echo Foo::test()."\n";
echo Bar::test()."\n";
?>
This works as expected outputting:
foo
bar
However, this concept becomes very inflexible when dealing with some aspects of inheritance. Consider a child class that needs to do additional work in its test() method and then called the parent test() method to do the normal work.
<?php
class Bar2 extends Foo
{
const TEST_CONST = 'bar2';
public function test()
{
//do class specific things
//try to continue the function chain
return parent::test();
}
}
?>
This will also output 'foo'. While I agree that in this case this concept does make sense, I do think it is important for there to be a way to have this function return 'bar2'. The way that would most make sense to me and still somewhat follow the rules is to change the return to static::test(); However this causes a seg fault in your current patch. I will do a little more checking to see why you are segfaulting here.
In either case without having some way to chain callers this is going to become a very annoying problem when utilizing inheritance with late static binding.
--
Mike Lively
http://www.ds-o.com