Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:81039 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 88108 invoked from network); 23 Jan 2015 11:05:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jan 2015 11:05:55 -0000 Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.199 imap11-2.ox.privateemail.com Received: from [192.64.116.199] ([192.64.116.199:50352] helo=imap11-2.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7B/00-21411-11B22C45 for ; Fri, 23 Jan 2015 06:05:53 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id DB3B78800D5; Fri, 23 Jan 2015 06:05:50 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at imap11.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap11.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tpxO3JavqR54; Fri, 23 Jan 2015 06:05:50 -0500 (EST) Received: from [10.129.108.65] (dab-yat1-h-20-10.dab.02.net [82.132.215.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 73EB68800A2; Fri, 23 Jan 2015 06:05:49 -0500 (EST) References: <53F8A1FF-C809-4DDF-9C6F-6916C3E4F044@ajf.me> <3251D635-D97C-4738-B537-935A6CC21E19@ajf.me> <54C17E2B.80708@garfieldtech.com> <8858EE5D-7472-41F7-9C38-091043100ABF@ajf.me> <20150123100248.GQ26114@phcomp.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: <20150123100248.GQ26114@phcomp.co.uk> Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Message-ID: Cc: "internals@lists.php.net" X-Mailer: iPhone Mail (12B440) Date: Fri, 23 Jan 2015 11:05:42 +0000 To: Alain Williams Subject: Re: [PHP-DEV] [RFC] Combined Comparison (Spaceship) Operator From: ajf@ajf.me (Andrea Faulds) Hi Alain, > On 23 Jan 2015, at 10:02, Alain Williams wrote: >=20 >> On Fri, Jan 23, 2015 at 12:24:25AM +0000, Andrea Faulds wrote: >>=20 >> Having it be the same as =3D=3D=3D would be inconsistent with our existin= g sorting and comparison behaviour, so I don=92t think it should be changed.= If we made it strict like that, we=92d also have to define a strict < and >= as well, otherwise we have a problem, because in some cases ($x !=3D=3D $y &= & !($x < $y) && !($x > $y)) is TRUE. >=20 > I think that you mentioned that you might come up with another RFC if <=3D= > is > successful - that would be for a <=3D=3D> operator. >=20 > You might want to mention that ... but it is more complicated if the opera= nds > are of different types - what does it return in that case ? FALSE ? But th= e same > as <=3D> if the types are the same ? The RFC did originally say that, Davey had thought of it. I'm not too keen o= n the idea and have removed that bit: I don't really think you can do any re= asonable "strict" ordering. An error on unmatching types is a royal pain, an= d I know this because I've had to deal with Game Maker Language which did th= is. Sorting by type is fairly unintuitive. I think that if people want strict ordering, it's trivial to implement the p= articular scheme they want using <=3D>, casts, type checks, or strcmp(). Thanks! -- Andrea Faulds http://ajf.me/=