Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60517 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54548 invoked from network); 8 May 2012 05:16:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 May 2012 05:16:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 69.28.242.152 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 69.28.242.152 rproxy1-a.cypressintegrated.com Received: from [69.28.242.152] ([69.28.242.152:2812] helo=rproxy1-a.cypressintegrated.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0F/72-30976-F0CA8AF4 for ; Tue, 08 May 2012 01:16:00 -0400 Received: from localhost ([192.168.87.152]) by rproxy1-a.cypressintegrated.com (Brand New Heavy v1.0) with ASMTP id SKX31257 for ; Tue, 08 May 2012 01:15:57 -0400 Date: Tue, 8 May 2012 01:16:10 -0400 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <9576419.20120508011610@cypressintegrated.com> To: internals@lists.php.net In-Reply-To: References: <4F847B8A.9010007@sugarcrm.com> <733bc8ea59cf6737563a62886e92fcb6.squirrel@www.l-i-e.com> <4FA7C229.9080901@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [off] PHP: a fractal of bad design From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) > At most, I'd remove the part that truncates numeric strings like > "123abc" and always convert them to 0, because that's almost *never* > an intended effect. I too find it hard to think of the situation in which data must be stored, even in a temporary form, as "123abc" but is meant to be equivalent to 123. But it obviously has happened a bunch after all these years. Maybe a non-accidental example is where "123a", 123b", and "123c" are all expected to be juggled to 123 -- i.e. the code is purposely utilizing the PHP behavior in place of explicit truncation in order to group certain items together. I'm 99.999% sure I've never done this, but it would be devilishly hard to find the bugs that would come from changing this behavior. Enough that I could see it being a major event that tarnishes the release of PHP-dot-whatever-makes-this-change. I also want to point out, as I did the other month when this came up, that MySQL does autoconversion that is identical to this case [1], and with **MP pairings so absurdly common, it makes sense to keep this behavior in PHP for this reason alone. -- S. [1] SELECT '123abc' = 123 // true in MySQL (but not in all RDBMSes) > One could argue that "123" == 123 is, however. > On May 7, 2012, at 6:25 PM, Raymond Irving wrote: >> I was very surprised when I came across the == issue sometime ago. IMO >> strings should be compared as strings. They should never be converted to >> integer. >> >> >> 1=="1" // always convert the number value to a string and then >> compare it >> "foo" == 0 // should return false >> >> "123abc" == "123nth" // compare as string. Do not convert to numeric values >> >> "0"==0 // true >> 0=="0." // false >> >> PHP is great but if we can work together to remove the flaws, then we can >> make it even greater. We have to leave the past behind us and look at where >> we want PHP to be in the next 5 years >> >> >> Best regards,