Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76722
Return-Path: <php@mabe.berlin>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 77298 invoked from network); 20 Aug 2014 09:22:20 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 20 Aug 2014 09:22:20 -0000
Authentication-Results: pb1.pair.com smtp.mail=php@mabe.berlin; spf=permerror; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=php@mabe.berlin; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.171 cause and error)
X-PHP-List-Original-Sender: php@mabe.berlin
X-Host-Fingerprint: 80.237.132.171 wp164.webpack.hosteurope.de  
Received: from [80.237.132.171] ([80.237.132.171:42078] helo=wp164.webpack.hosteurope.de)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id C5/00-11231-AC864F35 for <internals@lists.php.net>; Wed, 20 Aug 2014 05:22:19 -0400
Received: from dslc-082-082-189-238.pools.arcor-ip.net ([82.82.189.238] helo=[192.168.178.27]); authenticated
	by wp164.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
	id 1XK25u-0004FI-RO; Wed, 20 Aug 2014 11:22:14 +0200
Message-ID: <53F4689C.30809@mabe.berlin>
Date: Wed, 20 Aug 2014 11:21:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Tjerk Meesters <tjerk.meesters@gmail.com>, =?UTF-8?B?Sm9oYW5uZXMgU2No?=
 =?UTF-8?B?bMO8dGVy?= <johannes@schlueters.de>
CC: Sara Golemon <pollita@php.net>, 
 PHP internals <internals@lists.php.net>
References: <53F1094B.4040100@mabe.berlin>	<CAESVnVr3QJ56Ynu1cN+745fZEkq+Qas=5ecvQcF0jBX7QhdaMg@mail.gmail.com>	<53F1F534.50109@mabe.berlin>	<1408373244.2617.344.camel@guybrush>	<37CD1B56-B84F-4586-A631-F3C7F2547FBE@gmail.com>	<1408375856.2617.353.camel@guybrush> <CAHMUw2E_RxxbBfCyZmSPqhzwTdvHueqCJT9=3=m87t0BTHGNEw@mail.gmail.com>
In-Reply-To: <CAHMUw2E_RxxbBfCyZmSPqhzwTdvHueqCJT9=3=m87t0BTHGNEw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-bounce-key: webpack.hosteurope.de;php@mabe.berlin;1408526539;066c1054;
Subject: Re: [PHP-DEV] [RFC] Binary String Comparison
From: php@mabe.berlin (Marc Bennewitz)



On 19.08.2014 05:07, Tjerk Meesters wrote:
>
> On Mon, Aug 18, 2014 at 11:30 PM, Johannes Schlüter
> <johannes@schlueters.de <mailto:johannes@schlueters.de>> wrote:
>
>     On Mon, 2014-08-18 at 23:09 +0800, Tjerk Meesters wrote:
>      > > On 18 Aug, 2014, at 10:47 pm, Johannes Schlüter
>     <johannes@schlueters.de <mailto:johannes@schlueters.de>> wrote:
>      > >
>      > >> On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote:
>      > >> The question isn't "What's wrong with ===, strcmp()?" but
>     "What's wrong
>      > >> with ==, <, >?".
>      > >>
>      > >> We have a standard way to compare two operands but currently
>     we do some
>      > >> magic things to solve something that don't need to be solved.
>      > >
>      > > Still it is a key property of the language which we can't
>     simply change.
>      > > Also mind this: All input data are strings and some databases also
>      > > return data as string. So code like
>      > >
>      > >   if ($_GET['id'] > 0)
>      > > or
>      > >   if ($db->fetchRow()[0] == 12)
>      > >
>      > > which is common will break.
>      >
>      > Those two cases will actually not be affected, it's strictly
>     string<=>string comparisons that's being discussed here.
>
>     Meaning that simple code you find everywhere, in every second tutorial
>
>         foreach ($db->query("SELECT id, title FROM entries") as $row) {
>             echo "<tr><td";
>             if ($row[0] == $_GET['highlight_id']) {
>                 echo " background='#ff0000'";
>             }
>             echo ">".htmlentities($row[1])."</td></tr>";
>         }
>
>     will suddenly fail. How wonderful! (irony)
>
>
> Not necessarily and certainly not by definition; reasons for failure are
> less obvious such as (but not limited to):
>
> "0" == "0.0"
> "11" == " 11" (but note that "11" == "11 " currently yields false)
> "0" == ""
>
> I'm not arguing for or against this behaviour change, but I found it
> necessary to clear up some apparent confusion as to what repercussions
> this proposal carries.
>
> Another approach of attempting to solve the common issue of comparing
> big numbers with '==' is to only enforce string-wise comparison if a
> number cast would cause precision loss.

That's a good point, too

>
>
>     johannes
>
>     ps. yes, the example might be done nicer and better, it still represents
>     a common pattern.
>
>
>
>
> --
> --
> Tjerk