Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49851
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: internals@lists.php.net
References: <AANLkTimG-BJyqvf5-6iFJ5Q6e5FouL+9mnkTNVmsKi+r@mail.gmail.com>
 <1285856641.16846.92.camel@guybrush>
 <alpine.DEB.2.00.1009301547030.2461@kossu.derickrethans.nl>
 <AANLkTikpiKnm2fAVwbumFdsnOoCVib0GPKtBKaKn6Mev@mail.gmail.com>
 <1286115365.2606.302.camel@guybrush>
 <op.vjz7iai6idpuyk@damnation.dulce.lo.geleia.net>
 <1286116661.2606.313.camel@guybrush>
Date: Sun, 03 Oct 2010 18:34:31 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_IST?=
Message-ID: <op.vj0gft1zidpuyk@damnation.dulce.lo.geleia.net>
In-Reply-To: <1286116661.2606.313.camel@guybrush>
User-Agent: Opera Mail/10.62 (Win32)
Subject: Re: [PHP-DEV] RFC: Comparable interface
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Sun, 03 Oct 2010 15:37:41 +0100, Johannes Schl=C3=BCter  =

<johannes@schlueters.de> wrote:

> On Sun, 2010-10-03 at 15:21 +0100, Gustavo Lopes wrote:
>>
>> I actually see no reason why we shouldn't expose the compare overload=
 we
>> already have for internal classes to userspace classes.
>
> For internal classes it is needed, as they extend zend_object with
> custom information we don't find in hash tables etc. so without the
> internal handler we can't decide whether two objects are equal or not.=

>
>> However, the patch goes much further than this and, even if that  =

>> direction were desired, it takes, in my opinion, the wrong options in=
  =

>> the
>> details I've mentioned.
>
> For userspace-defined classes the equal and other comparison operation=

> are clearly defined. (Well, maybe some of the conversions aren't alway=
s
> that clear, but still follow rules)
>
> When adding this feature the comparison operators change their
> meaning ...

You raise a fair point -- the motivation to override the comparison  =

operator for internal classes is indeed bigger because the state is not =
in  =

the usual places. However:

* The functionality already exists; comparison operators already have  =

their meaning "changed" (read: user-defined) for some objects.
* I'd argue the current behavior (comparing classes and properties) is o=
f  =

limited use for equality. It's common to lazy-load the properties of the=
  =

objects, which makes the current comparison behavior unreliable.
* The current behavior for >, <, etc. is completely useless. It's  =

unpredictable and it doesn't even establish a total order:

$a =3D new stdclass;
$a->prop =3D null;
$b =3D new stdclass;
$b->prop2 =3D null;

var_dump($a > $b); //false
var_dump($a =3D=3D $b); //false
var_dump($b > $a); //false



-- =

Gustavo Lopes