Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103090
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.196 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVpp7z4QA4h=LJwnVnN+B8R27UVf+upzK9vpfXPuSE+Yqg@mail.gmail.com>
References: <CAESVnVpwGGaFW8s=MHp_Z1d6YjYEL0E8-QdFqwza5Fj5u0vYaA@mail.gmail.com>
 <03a9b282-1a46-c2a6-6987-0f2778f99be4@gmx.de> <d274fe49-3b96-7fc8-f591-b6a5c1be43ff@gmail.com>
 <CAESVnVpp7z4QA4h=LJwnVnN+B8R27UVf+upzK9vpfXPuSE+Yqg@mail.gmail.com>
Date: Mon, 13 Aug 2018 10:24:03 +0200
Message-ID: <CAF+90c_kPD_XYJF8RUuyLJ-mBbfRevm69N0nf_NQvCzcWFgTxg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, "Christoph M. Becker" <cmbecker69@gmx.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fb9a9c05734cd0e6"
Subject: Re: [PHP-DEV] Re: The curious case of the comparable objects.
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000fb9a9c05734cd0e6
Content-Type: text/plain; charset="UTF-8"

On Sun, Aug 12, 2018 at 6:43 PM, Sara Golemon <pollita@php.net> wrote:

> 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.
>

I'd recommend against fixing active branches -- this is quite likely to
break some tests using sort() somewhere (even if there is no resulting
functional change), while the fix itself is probably very niche.

Nikita


> > 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--000000000000fb9a9c05734cd0e6--