Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44386
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: PHP internals <internals@lists.php.net>
Message-ID: <42D6D0DF-726B-41B7-9AC2-9FC5EA8A7ED9@pooteeweet.org>
To: Lester Caine <lester@lsces.co.uk>
In-Reply-To: <4A3DEE3D.9000303@lsces.co.uk>
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 10:29:42 +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>
Subject: Re: [PHP-DEV] PHP 5.3.0RC4
From: mls@pooteeweet.org (Lukas Kahwe Smith)


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 to =20=

>>> 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 and =20=

> drop it in, forgetting that it's now on the 'deprecated' list. I =20
> 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 you =20=

need to know the code or familiarize yourself with the code if you =20
want to "fix" it, though per se .. there is nothing broken with the =20
code in the current version of PHP.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org