Req #78841 [NEW]: Unable to override a private function when called from parent class
| From: | andrew at nicols dot co dot uk | Date: | Wed, 20 Nov 2019 07:05:35 +0000 |
| Subject: | Req #78841 [NEW]: Unable to override a private function when called from parent class | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-223805@lists.php.net to get a copy of this message | ||
From: andrew at nicols dot co dot uk
Operating system: Any
PHP version: 7.4.0RC6
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:Unable to override a private function when called from parent class
Description:
------------
If I have a class which defines a private function (innerClick), and a
public function (click).
And I have the public function call the private function.
And I then extend the class.
It is possible to define a new implementation of the innerClick()
function.
HOWEVER... it is not called by any function in the original class.
AND no error or warning is ever shown.
The following example attempts to demonstrate:
https://3v4l.org/XL6O1
The innerClick function is called from a click function.
I have extended the base class and instantiated that new class.
When I call the public function on the child class (which is actually in
the base class), it calls the innerClick function on the base class.
This behaviour seems to have changed between PHP 5.1 and 5.2.
This behaviour makes sense when you consider that the original class is
aware that the original functions were private, and therefore as per the
strictest interpretation of visibility rules ("Private limits visibility
only to the class that defines the item"), however it is extremely
counter-intuitive.
I would argue that, as a minimum:
a) a warning should be shown to the user
In an ideal world I would argue that:
b) support of the current behaviour should be deprecated
In future I would argue that:
c) the behaviour flips and it becomes possible to call an overridden
version of the private function in a child class
It looks like this behaviour has previously been raised in #37320 and
was closed as not a bug. I would argue that this should be re-considered
given many of the other recent changes and RFC that have been voted upon
to improve the consistency of the language.
This is a confusing behaviour and should, at the very least, show a
warning.
Test script:
---------------
<?php
class base
{
public function click()
{
$this->innerClick();
}
private function innerClick()
{
echo "Called innerClick from base.\n";
}
}
class extension extends base
{
protected function innerClick()
{
echo "Called innerClick from extension.\n";
}
}
$example = new extension();
$example->click();
Expected result:
----------------
Called innerClick from extension.
Actual result:
--------------
Called innerClick from base.
--
Edit bug report at https://bugs.php.net/bug.php?id=78841&edit=1
--
Fix committed: https://bugs.php.net/fix.php?id=78841&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=78841&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=78841&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=78841&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=78841&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=78841&r=support
Expected behavior: https://bugs.php.net/fix.php?id=78841&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=78841&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=78841&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=78841&r=globals
PHP version support discontinued: https://bugs.php.net/fix.php?id=78841&r=phptooold
Daylight Savings: https://bugs.php.net/fix.php?id=78841&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=78841&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=78841&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=78841&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=78841&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=78841&r=mysqlcfg