Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56481 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45894 invoked from network); 23 Nov 2011 05:23:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Nov 2011 05:23:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.123 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.123 smtp123.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.123] ([67.192.241.123:44290] helo=smtp123.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EA/00-45113-2338CCE4 for ; Wed, 23 Nov 2011 00:23:00 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp22.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 9FEAD170C54; Wed, 23 Nov 2011 00:22:55 -0500 (EST) X-Virus-Scanned: OK Received: by smtp22.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 3ABB517039E; Wed, 23 Nov 2011 00:22:55 -0500 (EST) Message-ID: <4ECC832E.3080306@sugarcrm.com> Date: Tue, 22 Nov 2011 21:22:54 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Etienne Kneuss CC: Daniel Convissor , PHP Internals List References: <20111123015008.GA12933@panix.com> <20111123023108.GA172@panix.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! On 11/22/11 6:36 PM, Etienne Kneuss wrote: > PEAR is definitely doing some strange things :) Is it checking indices > of a variables without checking first if it's an array? > Sounds like the comeback of "Please don't break bad code!" seen with is_a :) I think somebody should start a code cleanup effort :) We can't build all PHP development around preserving every line of bad code doing bad things around. We care about BC but there should be some limits, and bug compatibility is beyond those limits. We long had array access syntax on strings. Expression $a[0]["foo"] where $a[0] is a string has long been treated as $a[0][0] and returned first letter of $a[0] (btw code doing this is already a bug, even though PHP lets you get away with it - but I'd put some notice there). Since this letter is a string, it should behave the same as other strings. Otherwise this code: echo $a[0]["foo"]["bar"] and this one: $b = $a[0]["foo"]; echo $b["bar"]; behave differently, which was a huge WTF and can only be considered a bug. Any code relying on this should be considered a bug too and fixed immediately. I can not think of any legitimate reason for the code to rely on such things. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227