Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79081
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <546F4FD3.6060509@lsces.co.uk>
Date: Fri, 21 Nov 2014 14:44:35 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAFMT4NpJxuuqc-wTr1aE4K+wZBT8+04j+9-SsY+nhUMU83fDUg@mail.gmail.com> <546C9E22.6090301@fedoraproject.org> <20141119134632.GV2294@phcomp.co.uk> <546CA8C0.1060707@gmail.com> <20141119143329.GX2294@phcomp.co.uk> <1416476628.15061.4.camel@kuechenschabe> <CAFMT4NoHNKHmck_rkAEWo9zx8A1Z5d_pTtaC+jOGXqV7SxkUAQ@mail.gmail.com> <1416502819.15061.38.camel@kuechenschabe> <CAFMT4NoCDJgnG554LO-yNzQ5TYpLVfx7FuaJHMHw_tO-H0Utkw@mail.gmail.com> <D2E30951-4407-4D2D-BA03-D9BB0C1B66C6@gmail.com> <546F0AA5.30805@lsces.co.uk> <546F2283.5070105@gmail.com> <546F2F5F.6010409@lsces.co.uk> <20141121133615.Horde.P-M9Rdh0CFRidC7Wj6bBaQ6@neo.wg.de> <546F3DB0.2040002@lsces.co.uk> <546F4910.8040909@gmail.com>
In-Reply-To: <546F4910.8040909@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
From: lester@lsces.co.uk (Lester Caine)

On 21/11/14 14:15, Rowan Collins wrote:
> Lester Caine wrote on 21/11/2014 13:27:
>> No - There have been several threads on deprecating things that are
>> currently 'hidden' by e_strict. The confusion is created by having two
>> incompatible styles of coding, and unless one brings the 'non-e_strict'
>> code in to line with current practices it creates problems when other
>> actions change the goal posts yet again.
> 
> So, that would be moving from E_STRICT (safe to hide) to E_DEPRECATED
> (less safe to hide). At that point, you can deal with the E_DEPRECATED
> notices *and carry on ignoring E_STRICT*.
> 
> Unless you can name an example of something which went from E_STRICT to
> fatal error? If so, that specific case was a violation of process, and
> should be highlighted.

IF one is working through code to fix the deprecated warnings why would
one not fix the remaining e_strict. In may cases they are all in the
same area of the code base? That is the whole point here ... we can't
assume that the code will continue to work in the future.

>> The confusion is created by having two incompatible styles of coding
> 
> I asked this before, and you didn't answer: can you name something
> which, when you fix the E_STRICT notice, makes your code incompatible
> with something else? Or something which, if you *ignore* an E_STRICT
> notice, refuses to work?

TODAY things are a little tidier, and problems that were created over
many upgrades and a lot of the problems have been fixed but it's the
agro caused when third party libraries re-enabling e_strict, hosting
changing settings for other reasons and problems like that. All cause
problems which will only be cleared when all of the legacy code is
updated ... which means making them e_strict compliant ... which IS
under-way, but slow going.

I have had many situations where having upgraded one library so it's
then e_strict clean it has problems when used with it switched off. In
my book, code runs clean, if it creates warnings/errors then it needs
fixing, and so simply hiding these is what is not acceptable.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk