Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:81055 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90478 invoked from network); 23 Jan 2015 22:20:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jan 2015 22:20:41 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.169 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.216.169 mail-qc0-f169.google.com Received: from [209.85.216.169] ([209.85.216.169:42061] helo=mail-qc0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 84/C1-15523-839C2C45 for ; Fri, 23 Jan 2015 17:20:40 -0500 Received: by mail-qc0-f169.google.com with SMTP id b13so23713qcw.0 for ; Fri, 23 Jan 2015 14:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=RP9rKA5Tr3CiwmSNK4UrzvhMOy5CfJC3g2k8+XUNLyo=; b=KOEYB0U1xz+ePUVnZRY+fGj8RwjTFfXPaGVWwTMsKLPKfeJudSozoqkvNR1E4GbucY nEOfPOeJbefclvmryXTRq3NQFV5BHg/UjfkVEQSXvfwKZpw7S7UB+Qp0HghFI4x6RaQI i+81Z7Kp6IkObuUp/I9OoqoBk456/mSkFm/oqzEYMSGKNEcNIj7qp4zh3b/q9GjgmWrJ 72+S3Q+EGiLtJ2HgA1zAqMZ39DrzTmPR3/wT1xwUp1Anpp9YURObC31a9QzmqTUPLT4w BkVRt639lPQBReIGcTZ600x1MF2ium3LLgi+E4lCgI/m0+vivhaartVmSRccCv3GjVty fZuA== X-Received: by 10.140.109.164 with SMTP id l33mr17793086qgf.91.1422051637191; Fri, 23 Jan 2015 14:20:37 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.229.93.70 with HTTP; Fri, 23 Jan 2015 14:19:57 -0800 (PST) In-Reply-To: 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> Date: Sat, 24 Jan 2015 07:19:57 +0900 X-Google-Sender-Auth: Jrm-K6TA2om3kdgsFOjkyNR1wMo Message-ID: To: Andrea Faulds Cc: Alain Williams , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a113a304eafe9f7050d59325d Subject: Re: [PHP-DEV] [RFC] Combined Comparison (Spaceship) Operator From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a113a304eafe9f7050d59325d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, On Fri, Jan 23, 2015 at 8:05 PM, Andrea Faulds wrote: > > On 23 Jan 2015, at 10:02, Alain Williams wrote: > > > >> On Fri, Jan 23, 2015 at 12:24:25AM +0000, Andrea Faulds wrote: > >> > >> Having it be the same as =3D=3D=3D would be inconsistent with our exis= ting > sorting and comparison behaviour, so I don=E2=80=99t think it should be c= hanged. If > we made it strict like that, we=E2=80=99d 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. > > > > 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. > > > > 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 <=3D> if the types are the same ? > > The RFC did originally say that, Davey had thought of it. I'm not too kee= n > on the idea and have removed that bit: I don't really think you can do an= y > reasonable "strict" ordering. An error on unmatching types is a royal pai= n, > and I know this because I've had to deal with Game Maker Language which d= id > this. Sorting by type is fairly unintuitive. > > I think that if people want strict ordering, it's trivial to implement th= e > particular scheme they want using <=3D>, casts, type checks, or strcmp(). The only reasonable behavior for <=3D=3D>, <=3D=3D, >=3D=3D would be raisin= g error/exception if type differs. E_RECOVERABLE_ERROR may be used. If anyone write RFC for these operators, I'll vote +1. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a113a304eafe9f7050d59325d--