Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:81038 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83576 invoked from network); 23 Jan 2015 10:02:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jan 2015 10:02:53 -0000 Authentication-Results: pb1.pair.com header.from=addw@phcomp.co.uk; sender-id=permerror Authentication-Results: pb1.pair.com smtp.mail=addw@phcomp.co.uk; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain phcomp.co.uk designates 78.32.209.33 as permitted sender) X-PHP-List-Original-Sender: addw@phcomp.co.uk X-Host-Fingerprint: 78.32.209.33 freshmint.phcomp.co.uk Received: from [78.32.209.33] ([78.32.209.33:52256] helo=mint.phcomp.co.uk) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 99/57-61273-B4C12C45 for ; Fri, 23 Jan 2015 05:02:52 -0500 Received: from addw by mint.phcomp.co.uk with local (Exim 4.72) (envelope-from ) id 1YEb4i-0001LF-Gx for internals@lists.php.net; Fri, 23 Jan 2015 10:02:48 +0000 Date: Fri, 23 Jan 2015 10:02:48 +0000 To: internals@lists.php.net Message-ID: <20150123100248.GQ26114@phcomp.co.uk> Mail-Followup-To: internals@lists.php.net 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8858EE5D-7472-41F7-9C38-091043100ABF@ajf.me> Organization: Parliament Hill Computers Ltd User-Agent: Mutt/1.5.20 (2009-12-10) Subject: Re: [PHP-DEV] [RFC] Combined Comparison (Spaceship) Operator From: addw@phcomp.co.uk (Alain Williams) On Fri, Jan 23, 2015 at 12:24:25AM +0000, Andrea Faulds wrote: > Having it be the same as === would be inconsistent with our existing sorting and comparison behaviour, so I don’t think it should be changed. If we made it strict like that, we’d also have to define a strict < and > as well, otherwise we have a problem, because in some cases ($x !== $y && !($x < $y) && !($x > $y)) is TRUE. I think that you mentioned that you might come up with another RFC if <=> is successful - that would be for a <==> operator. You might want to mention that ... but it is more complicated if the operands are of different types - what does it return in that case ? FALSE ? But the same as <=> if the types are the same ? -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include