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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
