Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85030
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain beccati.com designates 176.9.114.167 as permitted sender)
Message-ID: <5506C1ED.6080102@beccati.com>
Date: Mon, 16 Mar 2015 12:43:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c8fkaDu+xiCdQ2F6+MXMSyzvPkDcRjXCCs5YtEqpzsmZA@mail.gmail.com> <5505CFD2.5010609@beccati.com>
In-Reply-To: <5505CFD2.5010609@beccati.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] Reclassify E_STRICT notices
From: php@beccati.com (Matteo Beccati)

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/