Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85874 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4570 invoked from network); 19 Apr 2015 22:30:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Apr 2015 22:30:39 -0000 Authentication-Results: pb1.pair.com smtp.mail=cmbecker69@gmx.de; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=cmbecker69@gmx.de; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.18 as permitted sender) X-PHP-List-Original-Sender: cmbecker69@gmx.de X-Host-Fingerprint: 212.227.15.18 mout.gmx.net Received: from [212.227.15.18] ([212.227.15.18:64893] helo=mout.gmx.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 25/D0-34018-D8C24355 for ; Sun, 19 Apr 2015 18:30:38 -0400 Received: from [192.168.0.101] ([88.134.68.210]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MQiVh-1Yu9xv0FsT-00U4UR; Mon, 20 Apr 2015 00:30:34 +0200 Message-ID: <55342C8D.7020509@gmx.de> Date: Mon, 20 Apr 2015 00:30:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stanislav Malyshev , PHP Internals References: <54E35490.9040709@gmail.com> <5533A275.7050303@gmx.de> <55342724.6020606@gmail.com> In-Reply-To: <55342724.6020606@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:bha4JjjcS5z2ukt6CdPCKB/6sKUjicyxcmSA/vCYao6DuJosjp/ PXuKm2olSjeHMjYOqgLVhuJctFkLLCBULENZwLe92YMgza845iMLDDDRokzivQdu4BsUl57 +mb3IbHVFwiOl8IvD7Mojt4dcclX79Kl+nmGVamaOdwuL8JGa2XjS4ML7lJgdnoYp89WkID yzrk+cVrPdR8OLnyODWLw== X-UI-Out-Filterresults: notjunk:1; Subject: Re: [RFC] Spaceship operator RFC From: cmbecker69@gmx.de (Christoph Becker) Hi! Stanislav Malyshev wrote: > >> A discrepancy between the actual behavior of the spaceship operator and >> an example given in its RFC has been reported recently (bug #69466[1]). > > I'm not sure what the discrepancy is, could you explain? There is the following example in the RFC: // only values are compared $a = (object) ["a" => "b"]; $b = (object) ["b" => "b"]; echo $a <=> $b; // 0 But the actual result is currently 1, not 0. >> To me it appears that there is a contradiction in the RFC (see my >> comment on the respective report), which would have to be resolved one >> way or another. > > I don't see the contradiction. The objects in your example are not > comparable, since $a < $b and $b < $a are both not true, 1 is returned. > Returning 0 would be wrong of course since these objects are not equal. > In fact, there's no "right" value in this case as objects are not > comparable - so the result is undefined. In this case, undefined is 1. When there is no "right" value, why not raising E_NOTICE at least. It appears to me that returning 1 (as "undefined") without further notice is too misleading, as it suggests that $a is greater than $b, but that is not true: ($a > $b === false). -- Christoph M. Becker