Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103080
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.18 as permitted sender)
To: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
References: <CAESVnVpwGGaFW8s=MHp_Z1d6YjYEL0E8-QdFqwza5Fj5u0vYaA@mail.gmail.com>
Message-ID: <03a9b282-1a46-c2a6-6987-0f2778f99be4@gmx.de>
Date: Sat, 11 Aug 2018 15:34:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <CAESVnVpwGGaFW8s=MHp_Z1d6YjYEL0E8-QdFqwza5Fj5u0vYaA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
Subject: Re: The curious case of the comparable objects.
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 10.08.2018 at 17:12, Sara Golemon wrote:

> 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)

ACK.

> 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)

I tend to agree, even though the behavior is not really documented.  The
php.net manual says nothing about the ordering of objects, and the
language specification isn't clear about that, since it refers to array
comparison[1], but doesn't define the order of the properties.  Are
properties of parent classes inserted before the properties of child
classes?  Are ad-hoc properties inserted after the predefined ones?  Are
trait properties inserted where the are “use”d?  Are invisible
properties also part of the comparison?

> 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.

Fixing this for 7.3 is certainly okay; I'm not sure about former versions.

[1]
<https://github.com/php/php-langspec/blob/master/spec/10-expressions.md#user-content-relational-operators>

-- 
Christoph M. Becker