Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103086
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.195 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <d274fe49-3b96-7fc8-f591-b6a5c1be43ff@gmail.com>
References: <CAESVnVpwGGaFW8s=MHp_Z1d6YjYEL0E8-QdFqwza5Fj5u0vYaA@mail.gmail.com>
 <03a9b282-1a46-c2a6-6987-0f2778f99be4@gmx.de> <d274fe49-3b96-7fc8-f591-b6a5c1be43ff@gmail.com>
Date: Sun, 12 Aug 2018 11:43:05 -0500
Message-ID: <CAESVnVpp7z4QA4h=LJwnVnN+B8R27UVf+upzK9vpfXPuSE+Yqg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: The curious case of the comparable objects.
From: pollita@php.net (Sara Golemon)

On Sun, Aug 12, 2018 at 12:47 AM, Stanislav Malyshev
<smalyshev@gmail.com> wrote:
> Undefined behavior is undefined :)
>
(Ignoring your followup for a moment)
Even for undefined behavior, we should *try* to make the behavior
repeatable.  I know we wouldn't need to, but we should always go for
least surprise.
It's the side-effect hiding in the array cast from print_r/var_dump or
certain other presumable "read-only" actions causing the
interpretation of of the object compare that's maximum surprise.

>> <https://github.com/php/php-langspec/blob/master/spec/10-expressions.md#user-content-relational-operators>
>
> So looks like this part of the spec is violated, and I stand corrected -
> it's actually defined in this case, and should be fixed to follow the
> spec. I still think it makes little sense, but we have the spec, so we
> have to follow the spec.
>
> In this case, it's ok to fix it in all active versions - the spec wins I
> think. Or, we have to change the spec :)
>
Personally, I vote for fix on active branches, but it's not an urgent
bug, so I'll give some more time for feedback before pushing the PR
below.

> Depends on what the "fix" is, I assume.
>
I went with https://github.com/php/php-src/pull/3434 which has the
same overall complexity, though several more operations per element so
it'll be nominally less performant.  Alternate implementations
welcome.

-Sara