Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:49858 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45244 invoked from network); 3 Oct 2010 23:32:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Oct 2010 23:32:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=glopes@nebm.ist.utl.pt; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=glopes@nebm.ist.utl.pt; sender-id=unknown Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error) X-PHP-List-Original-Sender: glopes@nebm.ist.utl.pt X-Host-Fingerprint: 193.136.128.22 smtp2.ist.utl.pt Linux 2.6 Received: from [193.136.128.22] ([193.136.128.22:40208] helo=smtp2.ist.utl.pt) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F4/78-22289-78219AC4 for ; Sun, 03 Oct 2010 19:32:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 3E133700048C; Mon, 4 Oct 2010 00:32:20 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp2.ist.utl.pt ([127.0.0.1]) by localhost (smtp2.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id KzURD4wh4l5g; Mon, 4 Oct 2010 00:32:20 +0100 (WEST) Received: from mail2.ist.utl.pt (mail2.ist.utl.pt [IPv6:2001:690:2100:1::c]) by smtp2.ist.utl.pt (Postfix) with ESMTP id C101070003FA; Mon, 4 Oct 2010 00:32:19 +0100 (WEST) Received: from damnation.dulce.lo.geleia.net (52.152.108.93.rev.vodafone.pt [93.108.152.52]) (Authenticated sender: ist155741) by mail2.ist.utl.pt (Postfix) with ESMTPSA id A7A3C2006C2A; Mon, 4 Oct 2010 00:32:19 +0100 (WEST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Stas Malyshev" References: <1285856641.16846.92.camel@guybrush> <1286115365.2606.302.camel@guybrush> <1286116661.2606.313.camel@guybrush> <4CA90F4C.609@sugarcrm.com> Date: Mon, 04 Oct 2010 00:32:19 +0100 Cc: "internals@lists.php.net" 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: In-Reply-To: <4CA90F4C.609@sugarcrm.com> User-Agent: Opera Mail/10.62 (Win32) Subject: Re: [PHP-DEV] RFC: Comparable interface From: glopes@nebm.ist.utl.pt ("Gustavo Lopes") On Mon, 04 Oct 2010 00:18:36 +0100, Stas Malyshev wrote: >> * The current behavior for>,<, etc. is completely useless. It's >> unpredictable and it doesn't even establish a total order: >> >> $a = new stdclass; >> $a->prop = null; >> $b = new stdclass; >> $b->prop2 = null; >> >> var_dump($a> $b); //false >> var_dump($a == $b); //false >> var_dump($b> $a); //false > > That's because there's no total ordering of generic objects that can > make sense. Only very specific objects - such as ones representing > numeric qualities or having numeric properties - can be ordered, most of > objects are unordered. And comparing objects with scalars automagically > might bring a lot of surprises as nobody really expects $a == $b and $b > == $a to be different now. I never defended comparison of objects against scalars (though this is already possible, in a limited sense). Perhaps I ought to have changed the subject. I'm just saying that the current comparisons for user classes is either very limited (==) or completely useless (<, >, >=, <=). Given that, we could implement a *limited* mechanism for overloading those operators in user-land. If limited to objects of the same class (or with one operand of a subclass of the other), this could actually make the comparison operators useful with little potential for damage. It would also not be unprecedented since it's already allowed for internal classes. -- Gustavo Lopes