Hi!
I recall from earlier discussions that Stas was in favor of reverting this change -- what's the status at this time? This single change
I was not and still am not - I think if something warrants notice this is exactly the case. Conversion of array to string "Array" IMHO makes no sense and not useful in any case, so if you code does that it's most probably a bug. I understand that some tests were written without accounting for this, but frankly in this case I think the right way would be to fix the tests. This is not the feature your code should rely on (and I think it should have never existed in PHP in the first place) and if we shall guarantee compatibility with every bug and bad decision we took in the past we won't be able to advance anywhere. I think in this case the inconvenience from fixing the tests is outweighed by the advantage of promoting better code and exposing hard-to-find bugs.
* ob_get_status(true) does not always return an array
According to docs, ob_get_status(true) should return array, so it looks like a bug. Please submit a bug report.
* ob_get_clean() now raises a notice if no buffer to delete
This is where I say the notice is totally unneeded. Please submit a bug for it, it should be silent and return false, just as the docs say.
* Redefining a constructor with different arguments now results in E_FATAL Prior to 5.4.0RC1, if a concrete class added arguments to a constructor defined in an abstract class, no warning was raised. This behavior now results in an E_FATAL. I'm ambivalent about this change, however -- the code that raised this for us should be changed anyways. However, I'll argue, as others have on the list, that constructors should have the flexibility of redefinition without raising notices or compilation errors.
Here I agree with you, but looks like the majority disagrees. Though I'm not sure, frankly, what the point of defining ctor in the abstract class is, especially if argument list doesn't stay constant. Maybe clarifying this would change the opinion here.
* Introduction of the new keyword "callable" means that this can no longer be used for classnames, function names, or method names. We had one case where a "callable()" method was defined, and this now breaks; fortunately, it's only in tests, so we can easily fix it with no BC issues on our part. I'll note that I've also used the class|interface name "Callable" in the past on other projects. I'm okay with this change, but it needs to be clearly spelled out in the migration docs.
I will update UPGRADING, thanks. The existence of the callable hint is documented, but not the fact that it's reserved now.
Thanks for the testing! -- 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