At 10:02 10.12.2002, Zeev Suraski wrote:
Yes 007 is fixed now but private_007b.phpt still fails because the wrong method is being called.At 15:44 08/12/2002, Marcus Börger wrote:Looking into deep reveals that we must disallow overriding privates now.How do you arrive in that conclusion? The algorithm was designed to fully support it. Running private_007 also appears to be working for me (there was a buglet in the parser with static+access level, but if you remove the statics and/or update to the latest CVS, you can see that it's working fine...)
That way the test private_007.phpt is illegal and all current tests i developed
would pass (visibility tests are suspended of cause).
Zeev
The problem i see is the following: You inherit private methods to be slightly faster in zend_compile.
In zend_execute you fetch the fbc from the object. Doing this you fetch the wrong method.
All above assumes we were linking privates statically as we do in case of static methods. Or do we
link all static mehtods statically and all dynamic methods dynamic? If so the test has to be corrected.
Maybe the latter is better since it would be hard to explain that privates are linked statically while
public and protected are linked dynamically. I wrote the test based on my first patches and did not
allow to change the visibility. In that case it makes no sense to dynamically link privates. Now
increasing visibility is allowed all should be linked dynamically, shouldn't they?
Here is the test 007b:
=======================ptivate_007b.php
<?php
class Bar {
public function pub() {
$this->priv();
}
private function priv() {
echo "Bar::priv()\n";
}
}
class Foo extends Bar {
public function priv() {
echo "Foo::priv()\n";
}
}
$obj = new Foo();
$obj->pub();
$obj->priv();
echo "Done\n";
?>
=======================EOF
=======================ptivate_007b.log
---- EXPECTED OUTPUT
Bar::priv()
Foo::priv()
Done
---- ACTUAL OUTPUT
Foo::priv()
Foo::priv()
Done
---- FAILED
=======================EOF
marcus
