One of the contributors for the "Because, PHP" page came up with a fun
example where the result of object comparison changes upon observation
of that object.
class A { public $a; }
class B extends A { public $b; }
$a = new B(); $a->a = 0; $a->b = 1;
$b = new B(); $b->a = 1; $b->b = 0;
var_dump($a < $b); // bool(true)
print_r($a); // Output is unimportant
var_dump($a < $b); // bool(false)
Tracked this down to the introduction of slotted object properties
introduced in PHP 5.4 and some optimistic logic contained in
zend_object_handlers.c.
TL;DR - The print_r is materializing the ->properties HashTable in the
first object. Once that happens, zend_std_compare_objects() flips
from walking the slotted properties in properties_table to
materializing both ->propoperties HashTables and using a symtable
compare. The result differs, because rebuild_object_properties walks
->properties_info which may not necessarily be in the same order as
the values ->properties_table.
See also my writeup here: https://3v4l.org/NLZNm
So the questions for us are:
1. Does this matter? (I think so, it's spooky action at a distance)
2. Is it a bug introduced in 5.4 that's okay to fix? Or would fixing
it count as a BC break due to how long it's been broken? (I say
fixable bug, the BC break was at 5.4)
3. If yes to 1&2, how far back do we fix it? Bugfix branches (7.1+)?
Or would a change like this in branch be too much? Surely at least 7.3
could be fixed.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
