Lukas Kahwe Smith wrote:
There is a reason why E_DEPRECATED isn't part of E_ALL. Anyways, its
your call, but its not what we suggest. But overall there is always
room for doc improvements (feel free to help out), but in the end you
need to know the code or familiarize yourself with the code if you
want to "fix" it, though per se .. there is nothing broken with the
code in the current version of PHP.
Ok, guess I am wrong here. Its part of E_ALL as I suggested it when I
proposed E_DEPRECATED initially. Since it seems I was the only one that
considered not including it in E_ALL.
That being said, for development we currently suggest:
error_reporting = E_ALL | E_STRICT
And for production:
error_reporting = E_ALL & ~E_DEPRECATED
So I guess we are pushing people towards fixing deprecation issues a bit
more forcefully than I thought.
I must say that is does annoy me when I download a PHP package to have a
look at, and since my systems all run with display_errors=on, these
packages are somewhat unusable because of various warning messages.
Ignoring messages like these is simply pointless - they should be
handled and cleared up - which is why SOME of the decisions on what will
be removed causes a lot of agro to which "Just switch it off!" is NOT an
adequate response? We ARE expected to fix these things since that is
what the people who pushed the changes through expect to happen anyway
so that they can be removed quicker? :(
--
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//
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
