Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49821
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: <op.vjupw2y8idpuyk@damnation>
References: <AANLkTimG-BJyqvf5-6iFJ5Q6e5FouL+9mnkTNVmsKi+r@mail.gmail.com> <op.vjupw2y8idpuyk@damnation>
Date: Thu, 30 Sep 2010 23:25:28 +0800
Message-ID: <AANLkTi=N0dHa_b23OZUBXkbCu9zOGUvKrtyHCHGWLN=P@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] RFC: Comparable interface
From: aharvey@php.net (Adam Harvey)

On 30 September 2010 23:13, Gustavo Lopes <glopes@nebm.ist.utl.pt> wrote:
> That is, you would only modify zend_std_compare_objects (not
> compare_function!) and add there the additional logic where you'd check if
> the objects had the same class (or perhaps one was of a subclass of the
> other, in which case you'd use the compare method of the subclass) and call
> the compare method.
>
> Allowing comparison of objects with non-objects can become very confusing:
>
> * What if the objects are not of the same class? What if one is of a
> subclass of the other? Is equality not symmetric?
> * How do you interact with 'get' and 'cast_object'/'__tostring'?

The initial version of the patch actually did just that: it simply
modified zend_std_compare_objects. That's pretty much the cleanest way
you could do it. :)

I dropped it and went with the more complicated approach involving
changing compare_function because I actually think allowing comparison
with non-objects is a valuable feature. Objects may be more strongly
typed in PHP than scalars, but there's still a certain amount of
juggling that can take place via __toString(), so I think it would be
out of place to require an object on both sides. Additionally, there
are already semantics built into compare_function to handle
object/non-object comparisons, although they're of very limited use in
practice.

The specific use case I had in mind was allowing comparisons of
objects representing monetary amounts against numeric values (since
that was a particular itch I had a couple of years ago), but I'm sure
there would be others.

In terms of the specific question as to whether equality is symmetric:
certainly it should be, but we would have no way of enforcing it,
obviously. Java doesn't either, though: there's simply a note in the
documentation saying that implementations should be symmetric.

Adam