Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56585
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender)
Message-ID: <4ECEB260.4080605@sugarcrm.com>
Date: Thu, 24 Nov 2011 13:08:48 -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: Larry Garfield <larry@garfieldtech.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <20111123015008.GA12933@panix.com> <CACQesk6UuGUgyJz3hsGVE0crJx3GCkjTTpLb4xNGTm1goLzO8Q@mail.gmail.com> <20111123023108.GA172@panix.com> <CACQesk5kj=4kzvTDiLL1oOLBXZrn4WdUcLXdbyMLTa=OdhGTcw@mail.gmail.com> <4ECCB549.904@lsces.co.uk> <4ECCBC56.3050602@sugarcrm.com> <20111123141408.GA11940@panix.com> <20111123153100.GB13420@panix.com> <CAKUjMCVkmd2+=K9n6XVMeKvMCaMwORQN-3phA2CqZVjXBChPSg@mail.gmail.com> <4ECD37D9.8090604@lsces.co.uk> <4ECEA547.9070605@garfieldtech.com>
In-Reply-To: <4ECEA547.9070605@garfieldtech.com>
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!

> This is going to be a huge problem for Drupal.  Drupal uses deep
> associative array structures a lot, by design.  That means we isset() or
> empty() on arrays a lot.  I haven't had a chance to test it yet, but I
> see this change breaking, um, A LOT.  And as Daniel noted, the fix is to
> turn one line of very readable code into 8 lines of hard to read code.

Well, I do not think we're going to break the engine in a way that will 
act as it acted in 5.3 - to introduce new pseudo-type that works with 
$a[0] but not with $a[0][0] and bring in all the old bugs, even if 
Drupal relies on some side effect of them. I am not a Drupal developer 
so I have no idea why Drupal would use side effects of string offset 
bugs to distinguish between arrays and strings, but this is a wrong 
decision and needs to be changed, since among other things it means that 
code like isset($foo[0][0]) and $bar=$foo[0]; isset($bar[0]); works 
differently, which makes no sense.

So the question is - what can be done that works with 5.4 engine and is 
consistent, but will be better for Drupal and others that made similar 
mistakes of relying on a bug in pre-5.4 implementation of string offsets?

> Please roll it back to avoid breaking a crapton of existing, legitimate,
> non-buggy code.

Again, there's no "rolling back" this change, unless you want to throw 
out all 5.4 improvements in the engine, on which stage we might as well 
throw out whole 5.4 thing and forget about improving PHP, since it may 
disrupt somebody's code that relies precisely on the bugs being fixed. 
Sorry for being dramatic, but I've repeated it three times already so 
I'd really want for it to sink in this time - this change is an integral 
part of 5.4 engine cleanup and it can not be changed without seriously 
breaking the engine - because the way string offsets work now is the 
right way for them to work (or at least light years more right that what 
happened in 5.3).
So unless somebody comes with a patch that proves me wrong and shows me 
how old broken way of doing string offsets can be preserved without 
messing up a lot of things in the engine - there's not "rolling back" 
and no "reverting", there's nothing to roll back and revert.
If, however, anybody has any practical solution to it that improves 
things - he's more than welcome to come up with the patch and discuss 
it. I'll think about it too, but since I have no idea what Drupal does 
I'm not sure if the direction I choose would be best.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227