Hi Nikic,
On 15/03/2015 19:30, Matteo Beccati wrote:
In PHP4 times it was in fact quite common to change inherited method
signatures to bend them to one's will and/or remove parameters and
hardcode them in the parent constructor call. We now know it is bad
practice, but I bet there's lot of code using these practices in
controlled situations.
I'm going to attempt fixing the app code (including the bundled pear
libs) and report back.
So... I've spent a few hours on the cleanup and I'm still far from
getting a green build.
As you mentioned in the RFC, turning E_STRICT into E_WARNING is going to
be a BC-break for someone, and fixing this one in particular requires
far more effort than a simple search/replace.
For some applications it means heavy refactorings to ensure that all the
inherited methods have a compatible signature. That's enforced even if
the classes were never designed nor are expected to be interchangeable
(e.g. PEAR and its packages, many of which extend PEAR itself), or if
some "shortcuts" have been made (e.g. function foo() {
parent::foo("BAR"); } ).
I agree that it's a wrong usage of inheritance and we shouldn't
encourage it, but maybe an E_NOTICE would be good enough to avoid such
design mistakes.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
