On 21.06.2009, at 10:29, Lukas Kahwe Smith wrote:
On 21.06.2009, at 10:24, Lester Caine wrote:
Lukas Kahwe Smith wrote:
On 21.06.2009, at 09:51, Lester Caine wrote:
Johannes Schlüter wrote:
On Sat, 2009-06-20 at 07:49 +0100, Lester Caine wrote:
While I know that ...
- All ereg functions are deprecated and emit E_DEPRECATED errors.
Use PCRE (preg_*()) instead.
... is accurate, I think a little more detail would help here,
since many of us probably did not know that 'split' was an ereg
function - for instance?
hm, the las version on the wiki listed them ...
In general: I'd like if people could come up with more details
and add
them to the docs. (See Rasmus's mail) So that this file is as
short as i
makes sense so people have a chance to be aware of as much
contents as
possible - and isn't scared away.
I was probably looking more for pointers to some extra
information. Part of the problem here is that the warnings are
being thrown in code that *I* did not write, so then one either
has to search for updated versions of a library or work out how
to fix them yourself - where I'd 'borrowed' the code originally.
Simply hiding E_DEPRECATED is likely to lead to even bigger
blowups later? :(
Actually E_DEPRECATED is only something you should enable
temporarily. Then you can alert either your own team, or the
project who's code you are using and move on. It simply tells you
that the code will break with the next major version. This is not
an end of world fatal error.
On a production site - probably - but I see no reason to disable it
on the development sites. It's all to easy to grab a bit of code
and drop it in, forgetting that it's now on the 'deprecated' list.
I avoid libraries that throw errors and will only work with
'display_errors=off'. If I need to use them then I will fix any
errors even if 'non-fatal' before using the code in production! So
before PHP5.3 is acceptable for production, any warning needs to be
addressed - at least in my book.
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.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
