Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78858
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
Message-ID: <545FE3BC.9020707@gmail.com>
Date: Sun, 09 Nov 2014 21:59:24 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CABRjmp-oqEVtX-igQWsr-JkFmitqxn4YsyJ=mnzyHCN9Kj7akA@mail.gmail.com> <CAH-PCH62GAecxC00aHgzgskG8zk58z1LBE1uBv81xtj6hRiy5w@mail.gmail.com> <3E2593DC-5755-48A6-8802-6F2FB3625778@ajf.me> <CAEZPtU5bdrgX3yfNZhPsWqrU6d5fw=vX78-iW=gx1jUJoeF8YA@mail.gmail.com> <04723EAD-4C8E-41C2-BE81-4989882A0C69@ajf.me> <545B26BB.9020406@lsces.co.uk> <545B589A.4010606@gmx.de> <545B66AB.2000109@lsces.co.uk> <545C2785.4010004@gmx.de> <545FD319.3040703@lsces.co.uk>
In-Reply-To: <545FD319.3040703@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Thresholds of backwards compatibility breaks
From: rowan.collins@gmail.com (Rowan Collins)

On 09/11/2014 20:48, Lester Caine wrote:
> On 07/11/14 01:59, Christoph Becker wrote:
>> Nobody suggested to switch off error reporting.  IMO, E_STRICT is
>> supposed to be a weak form of E_DEPRECATED, i.e. a hint for the
>> developer to modernize the code in the near future.  Until this can be
>> done, it seems to be perfectly fine to suppress *these* warnings.  When
>> the developer finds the time to fix the outstanding issues, running the
>> test suite in a development environment should catch most (if not all)
>> of them.  If there is no test suite, the developer is likely to be out
>> of luck anyway, IMHO.
>>
>>>> Screwing up the code and then hiding the results is NOT maintaining BC!
>> Apparently, the inclusion of E_STRICT to E_ALL wasn't supposed to screw
>> up anything.
> Incremental changes from one version to the next may work for some
> people. The problem is bringing Pre-5.2 code forward so that it can
> reliably co-exist with already 'fixed' code. Many of the ISP's who tried
> simply switching their shared hosting to 5.4 found that so many sites
> simply stopped working that they had to revert the change. It is not
> 'developers' who have to find the time to make legacy code work on
> current servers ... it's users who have no idea even where to start!
> That their site is simply producing a white screen is not a help so
> perhaps the 'defaults' would be better off in favour of the
> unsophisticated user rather than something that pleases developers? Not
> that it helps anyway since distributions all throw their own two pennies
> in, and the 'suggested fixes' fail because the files are not where we
> tell them. That is if the hosting company even allow access.
>

Well, in the scenario you just described, it is the service provider who 
is choosing a) the version of PHP, and b) the default configuration for 
users on their system. If somebody is running shared hosting and can't 
correctly work with an ini file, and read the release notes from 
php.net, they're probably in the wrong business. The users - if they're 
not developers - are presumably installing specific pieces of software 
created by known 3rd-parties; often, they are doing so using control 
panel tools provided by the hosting provider.

The hosting providers have to work with the users to find out if the 
software in use will work on a particular platform; but that's a case of 
asking the developers and getting an answer "yes" or "no" (or "soon"). A 
stronger compatibility between releases makes it easier for the 
developers to say "yes", but if there is no developer willing to fix it, 
even a single incompatible line (which is an inevitable risk if the 
language doesn't completely stagnate) is too much. (If you're willing to 
hack the code to make it work, you are, at that point, volunteering as a 
developer not a user.)

None of which has anything to do with E_STRICT. Strict notices aren't 
indications that behaviour has changed; since we have E_DEPRECATED, they 
shouldn't even indicate behaviour is about to change; they just indicate 
that there might be a better way of doing what you're doing. I don't 
know why you consider them to be in the same category as code 
compatibility at all.

-- 
Rowan Collins
[IMSoP]