Re: Results of testing ZF against PHP 5.4.0RC1

On 2011-11-17, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > > 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. I can live with this. > > * 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. Done: https://bugs.php.net/bug.php?id=60321 > > * 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. Done: https://bugs.php.net/bug.php?id=60322 > > * 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. Ralph has done this in a separate thread now. > > * 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. Excellent, thanks. > Thanks for the testing! Thanks for the release! :) -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc