Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49834
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <4CA4F301.1070005@sugarcrm.com>
References: <AANLkTimG-BJyqvf5-6iFJ5Q6e5FouL+9mnkTNVmsKi+r@mail.gmail.com> <4CA4F301.1070005@sugarcrm.com>
Date: Fri, 1 Oct 2010 10:57:18 +0800
Message-ID: <AANLkTin9KOXJacna+4dzV_Rf6yk4RVUy4SXgsULC_n3k@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] RFC: Comparable interface
From: aharvey@php.net (Adam Harvey)

For what it's worth, I'm planning to update the RFC later today with
an updated SPL-less patch and the start of a Q&A section similar to
what we've had in the other RFCs. I'll send an e-mail when it's ready.

On 1 October 2010 04:28, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> It is not clear from the RFC, if the engine encounters $a <= $b, what
> actually happens?
> E.g.:
> 1. Is only $a checked for Comparable or also $b?

Both $a and $b are checked.

> 2. How it is ensured that if $a < $b then $b > $a?

That's up to the userspace developer to get right when they're
implementing their compareTo method. I expect the manual would have a
dire warning about the possible consequences of not making them
equivalent.

> 3. Would sorting work with it?

Yes.

> 4. If both $a and $b are objects with different compare functions, how it is
> determined whose function is used? Note that operators like == are assumed
> to be commutative, and less/more operators are assumed to be commutative in
> pairs, like above.

The left operand wins, so $a.

> As a side note, if we have traits we might instead think of having
> Comparable trait or interface or both, which would declare having
> compareTo() standard feature (as Java does) without messing with the engine
> and overloading operators. Surely, it would be more verbose, but that might
> be a good thing.

I don't think that gains us an awful lot (it's no different to simply
having an interface or trait within a codebase requiring such a
function, which has been common practice in some of the systems I work
on anyway), but it'd be easy enough to add, obviously.

Adam