Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44387
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: Lester Caine <lester@lsces.co.uk>,
 PHP internals <internals@lists.php.net>
Message-ID: <A9CDA9A2-3607-4DBF-957D-822C9DE7ABB1@pooteeweet.org>
To: Lukas Kahwe Smith <mls@pooteeweet.org>
In-Reply-To: <42D6D0DF-726B-41B7-9AC2-9FC5EA8A7ED9@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Sun, 21 Jun 2009 11:48:20 +0200
References: <2F881AF5-845A-4CCD-8D9F-31D99C383C6F@pooteeweet.org>	 <4A3C8687.5090804@lsces.co.uk> <1245541002.6521.22.camel@goldfinger.johannes.nop> <4A3DE678.90706@lsces.co.uk> <0A98F482-ADE6-40C6-B62A-D9FD51B54AA8@pooteeweet.org> <4A3DEE3D.9000303@lsces.co.uk> <42D6D0DF-726B-41B7-9AC2-9FC5EA8A7ED9@pooteeweet.org>
Subject: Re: [PHP-DEV] PHP 5.3.0RC4
From: mls@pooteeweet.org (Lukas Kahwe Smith)


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=FCter 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, =20=

>>>>>> since many of us probably did not know that 'split' was an ereg =20=

>>>>>> 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 =20
>>>>> and add
>>>>> them to the docs. (See Rasmus's mail) So that this file is as =20
>>>>> short as i
>>>>> makes sense so people have a chance to be aware of as much =20
>>>>> contents as
>>>>> possible - and isn't scared away.
>>>>
>>>> I was probably looking more for pointers to some extra =20
>>>> information. Part of the problem here is that the warnings are =20
>>>> being thrown in code that *I* did not write, so then one either =20
>>>> has to search for updated versions of a library or work out how =20
>>>> to fix them yourself - where I'd 'borrowed' the code originally. =20=

>>>> Simply hiding E_DEPRECATED is likely to lead to even bigger =20
>>>> blowups later? :(
>>> Actually E_DEPRECATED is only something you should enable =20
>>> temporarily. Then you can alert either your own team, or the =20
>>> project who's code you are using and move on. It simply tells you =20=

>>> that the code will break with the next major version. This is not =20=

>>> an end of world fatal error.
>>
>> On a production site - probably - but I see no reason to disable it =20=

>> on the development sites. It's all to easy to grab a bit of code =20
>> and drop it in, forgetting that it's now on the 'deprecated' list. =20=

>> I avoid libraries that throw errors and will only work with =20
>> 'display_errors=3Doff'. If I need to use them then I will fix any =20
>> errors even if 'non-fatal' before using the code in production! So =20=

>> before PHP5.3 is acceptable for production, any warning needs to be =20=

>> addressed - at least in my book.
>
>
> There is a reason why E_DEPRECATED isn't part of E_ALL. Anyways, its =20=

> your call, but its not what we suggest. But overall there is always =20=

> room for doc improvements (feel free to help out), but in the end =20
> you need to know the code or familiarize yourself with the code if =20
> you want to "fix" it, though per se .. there is nothing broken with =20=

> 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 =20=

proposed E_DEPRECATED initially. Since it seems I was the only one =20
that considered not including it in E_ALL.

That being said, for development we currently suggest:
error_reporting =3D E_ALL | E_STRICT

And for production:
error_reporting =3D E_ALL & ~E_DEPRECATED

So I guess we are pushing people towards fixing deprecation issues a =20
bit more forcefully than I thought.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org