Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83296
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADajX4BQ_KTvdhNMr4ZA_n5HcZ_LUDsS4s3_2WeS9sezAPxsuA@mail.gmail.com>
References: <CADajX4BQ_KTvdhNMr4ZA_n5HcZ_LUDsS4s3_2WeS9sezAPxsuA@mail.gmail.com>
Date: Fri, 20 Feb 2015 14:20:48 +0100
Message-ID: <CAF+90c86g2wNT6CKGdoJA-YLm82vC2SBWwsXs+x24gLRcxAkRg@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bfcf000bb6c27050f84eb50
Subject: Re: [PHP-DEV] [RFC] Comparable: the revenge
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7bfcf000bb6c27050f84eb50
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 19, 2015 at 10:40 PM, Adam Harvey <aharvey@php.net> wrote:

> Hi all,
>
> Those of you with long memories will remember that I proposed a
> Comparable interface way back in the pre-5.4 days, but withdrew it
> when it became obvious that there was no consensus for it as a feature
> and that a vote was likely to fail.
>
> RFC: https://wiki.php.net/rfc/comparable
> PR: https://github.com/php/php-src/pull/1097
>
> Why reanimate it now, I hear you ask? I think that comparisons have
> only become more prominent in the language: we now have a spaceship
> operator for explicit comparisons, yet the behaviour of object
> comparisons can be obscure, to say the least, and the user has no
> control over how their objects are compared.
>
> At this stage, I intend to put this up for a vote on March 5 (vote
> ending March 12), with the obvious endgame being that this would be
> included in 7.0.
>

Some technical notes on the RFC text:
 * "How it is ensured that if $a < $b then $b > $a?" The RFC claims that it
is up to the developer to ensure this, however I don't think this is true.
As far as I know PHP will implicitly enforce this. It would be good if you
could double-check the behavior.
 * "If both $a and $b are objects with different compare functions, how it
is determined whose function is used" Here you answer that the left operand
wins. Once again I am unsure whether this is true - I'd assume that for >
and >= the right operand wins.
 * I would appreciate a note that indicates how non-total /
non-trichotomous comparisons can be implemented, namely by returning 1
irregardless of order. You can use a subset-relationship to illustrate this.
 * Have you considered the impact on exception-safety this may have? Did
you verify that all places where compare_function (or derivatives) are used
are exception-safe?

Nikita

--047d7bfcf000bb6c27050f84eb50--