Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85043
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fischer.name from 62.179.121.43 cause and error)
Message-ID: <5506CC8B.8020304@fischer.name>
Date: Mon, 16 Mar 2015 13:28:59 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c8fkaDu+xiCdQ2F6+MXMSyzvPkDcRjXCCs5YtEqpzsmZA@mail.gmail.com> <5505CFD2.5010609@beccati.com> <5506C1ED.6080102@beccati.com>
In-Reply-To: <5506C1ED.6080102@beccati.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam_report: Spam detection software, running on the system "scanner01.home", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hi Matteo, On 16.03.15 12:43, Matteo Beccati wrote: > 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. [...] 
 
 Content analysis details:   (-2.9 points, 5.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
Subject: Re: [PHP-DEV] [VOTE] Reclassify E_STRICT notices
From: markus@fischer.name (Markus Fischer)

Hi Matteo,

On 16.03.15 12:43, Matteo Beccati wrote:
> 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.

am I correct assuming that your existing test suite was running with
E_STRICT excluded from error_reporting ?

thank you,
- Markus