Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49823
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Adam Harvey" <aharvey@php.net>
Cc: internals@lists.php.net
References: <AANLkTimG-BJyqvf5-6iFJ5Q6e5FouL+9mnkTNVmsKi+r@mail.gmail.com>
 <op.vjupw2y8idpuyk@damnation>
 <AANLkTi=N0dHa_b23OZUBXkbCu9zOGUvKrtyHCHGWLN=P@mail.gmail.com>
Date: Thu, 30 Sep 2010 16:54:15 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_IST?=
Message-ID: <op.vjurspfridpuyk@damnation>
In-Reply-To: <AANLkTi=N0dHa_b23OZUBXkbCu9zOGUvKrtyHCHGWLN=P@mail.gmail.com>
User-Agent: Opera Mail/10.62 (Win32)
Subject: Re: [PHP-DEV] RFC: Comparable interface
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Thu, 30 Sep 2010 16:25:28 +0100, Adam Harvey <aharvey@php.net> wrote:

> 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. :)
>
> (...) 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.
>

It's true that the engine already allows comparison of objects with  
scalars, but that can only happen after a cast. At least you now have the  
guarantee that if you compare a scalar x of type u with an object y and  
they're equal, then x === (u) y is also true*.

With your patch, you could make $obj == "jjj" be true and (string) $obj  
yield a completely different thing. Obviously you wouldn't do this on  
purpose, my point is that this could lead to a hard to debug problem.

This is what makes me very reluctant to support this more general approach  
of allowing scalar-object comparisons.

* (maybe there's some edge case where this wouldn't happen because the  
engine is inconsistent with its preferences towards get, cast_object and  
__toString, but my point stands)

> 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.

Obviously it must be the programmer's responsibility to write a compare()  
function that is symmetric (and in general, establish a total order).

My point about about symmetry was another: you know have potentially  
different code running in these two cases:

$a == $b
$b == $a

The current implementation is "symmetric" in the sense the compare_objects  
handler is called only if both objects have the same handler (only the  
arguments are exchanged).


-- 
Gustavo Lopes