Hi Jay, > Is this fix really causing this much grief? Throwing an E_NOTICE isn't a BC > break. It still works as before, it just throws the E_NOTICEs now.
yes and yes :) Smart people (like Jan) write code that doesn't cause E_NOTICEs. Now they are faced with code that worked flawlessly before but raises all kinds of errors now. Before you say that "errors shouldn't be turned on in production", don't forget that smart people do turn off the errors, and have them go into an error log instead. Some people do magic and get mailed or paged when errors happen. > This was > meant to be a bridge to the behaviour used in PHP 5, which, like other > array_*() functions, doesn't work on non-arrays at all. (Although that fix > for PHP 5 is debatable, I suppose.) *IF* someone decides to upgrade to PHP 5, let them worry about PHP 5 behaviour then. > The function is called array_merge(), not null_merge() or string_merge(). > The change was to make it act more like other array functions, like > array_intersect() or array_sum(), which also check parameters for arrays. PHP is a loosely typed language. You've suddenly made it more strict in a minor release. Behaviour changing patches are not suitable for the *stable* branch. > What's the consensus? Keep the change or revert? Personally, I think it's > more consistent if it acts like the other array functions, but if it's > causing a lot of headaches... Revert - it will cause hundreds more people lots more headaches than you were having on your own :) > Just a thought -- perhaps keep it in for the first 4.3.4 RC and gauge the > reaction and go from there? No :) RC means release candidate, which means "this is what we are going to release if no one finds bugs". Actually, this is Ilia's decision, but I think we should not raise any notices for NULL values, for the sake of BC. It really does suck to break code that was working with no problems in a minor release. If the change had been made for 4.3, or 4.4 or 5, it wouldn't matter quite so much. But to change it for 4.3.4 !? --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
