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
