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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
