Bug #63976 [Asn]: Parent class incorrectly using child constant in class property

Edit report at https://bugs.php.net/bug.php?id=63976&edit=1 ID: 63976 Updated by: dmitry@php.net Reported by: don at smugmug dot com Summary: Parent class incorrectly using child constant in class property Status: Assigned Type: Bug Package: Class/Object related Operating System: Ubuntu 12.04 PHP Version: 5.4.10 Assigned To: dmitry Block user comment: N Private report: N New Comment: I understood the problem and your patch, I also agree what it fixes the problem for this particular case. Unfortunately, I afraid that it may break some applications, because it may make constant resolution early in the moment, when such constants were not defined yet. For example your patch is going to break the following script. <?php class A { public $x = X; } class B extends A { } const X = 1; $b = new B; var_dump($b); ?> I think the problem may be solved by substituting "self" and "parent" by actual class names at compile-time. It must be quite easy to do it for "self" (in zend_do_fetch_constant or in zend_do_declare_property), but not so easy for "parent" (we may use CG(parent_class_name) to solve it). Previous Comments: ------------------------------------------------------------------------ [2013-03-14 17:42:39] don at smugmug dot com I have validated that the patch solves our use case (and the test case in this bug). Thanks Mike! ------------------------------------------------------------------------ [2013-03-14 09:01:59] mike@php.net @dmitry, can you have a look at the , please? The condition could actually be simplified to if (ce->type == ZEND_USER_CLASS) ... Thank you. ------------------------------------------------------------------------ [2013-02-14 17:30:36] mike@php.net The following patch has been added/updated: Patch Name: update_class_constants Revision: 1360863036 URL: https://bugs.php.net/patch-display.php?bug=63976&patch=update_class_constants&revision=1360863036 ------------------------------------------------------------------------ [2013-01-12 03:53:33] don at smugmug dot com 'Have a preference' should have said 'I have a preference'. Certainly not intending for PHP to add some new INI option or something to change how static:: and self:: behave. :) Also, have confirmed this on 5.4.4 and CentOS in addition to Ubuntu and 5.4.10, both with and without extensions like APC loaded. ------------------------------------------------------------------------ [2013-01-12 03:51:21] don at smugmug dot com Description: ------------ Class properties that rely on potentially inherited class constants have unpredictable behavior. Since PHP doesn't support Child class properties referencing static values like static::CONST, the meaning of self::CONST is ambiguous. One of two things should happen: 1. It should use the value defined in the actual class in question (like self:: is used throughout the rest of PHP). 2. It should treat self:: in this case, since it's compile-time and not late static binding, like static:: and walk the inheritance tree, delivering the result for the Child class. Option #1 seems the most sane, but PHP often behaves like it intends #2 to work. But not always... In the provided examples, 'brokenA.php' behaves like #1, above, while 'brokenB.php' and 'brokenC.php' behave like #2. The only thing that's changed is the order in which the classes are require()'d. In a complex script, with autoloaders, class instantiation order isn't predictable, of course, resulting in unpredictable results. Test script: --------------- Example code: https://github.com/onethumb/php-parent-child-constant-bug Expected result: ---------------- Consistent results for Baz->table. Either 'foo' or 'baz' 100% of the time, rather than mixed up depending on require() order. Have a preference for adding static::CONST to PHP and making self::CONST behave like self:: does in the rest of the language (resulting in Baz->table == 'baz' in the examples if we used static::CONST), but if that's not preferable for some reason, self::CONST should probably behave like self:: everywhere else (resulting in Baz->table == 'foo' in the examples). Actual result: -------------- brokenA.php: Bar Object ( [table] => bar ) Baz Object ( [table] => foo ) brokenB.php: Bar Object ( [table] => bar ) Baz Object ( [table] => baz ) brokenC.php: Baz Object ( [table] => baz ) Bar Object ( [table] => bar ) Baz Object ( [table] => baz ) ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=63976&edit=1