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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
