|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2013-01-12 03:51 UTC] 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 ) Patcheszend_do_fetch_constant (last revision 2013-03-19 09:59 UTC by mike@php.net)update_class_constants (last revision 2013-02-14 17:30 UTC by mike@php.net) Pull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Thu Nov 21 12:01:29 2024 UTC |
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).