Re: [Fwd: E_ALL changes in 5.2/6.0]

On 5/14/06, Greg Beaver <cellog@php.net> wrote:

Hi all, This email is a rather troubling indication of things to come. PEAR is lagging sadly behind in terms of this. This change Marcus is talking about is going to cause applications that worked just fine in PHP 5.1.4 to suddenly spew lots of errors when using PEAR apps. This will only occur on sites that have error reporting and error display on, but it is a serious thing to consider. What is more crucial to consider is that *all* packages that make use of PEAR::raiseError() or any other non-static function called statically will not work in PHP 6.0. There are other changes forthcoming. Time to smell the coffee folks. We need to split off PHP5-syntax packages on the main site, as this will make a large difference as to how useful the site is for users. I proposed a "groups" system for doing this a little while back on pear-core: http://beeblex.com/lists/index.php/php.pear.core/4346 and although I have not yet implemented it in pearweb because I'm waiting for Pierre to finish his mystery new code and commit the damn thing (ahem) this needs to happen very soon. More to the point, we need to re-evaluate the rather listless direction of PEAR. PEAR has always been about filling in the gaps in PHP. Recently, the project has kind of forgotten about this fact in the effort to satisfy both users who refuse to upgrade PHP and users who do upgrade PHP. We're in a tight spot. I don't have immediate answers, but I would like to see more useful innovation happening in PEAR. I'm not going to be able to take the lead on this question until the summer is over, due to terrible internet access for most of July and August among other things. However, I can get things started. I would like you all to consider this a friendly "get-off-your-ass" prod to start at least thinking about the problem. I only have one request: please do not post a reply with a solution until you have asked at least one other developer off-list what they think of your solution. We need carefully thought-out brilliant solutions or it will just clog the list :).

Greg, while I understand your sentiment, I have no idea what Marcus Boerger is saying below and so have no idea what the "changes" you refer to are. IMHO PHP6 problems are not ones that necessarily need to be worried about right now. PHP5 is just now becoming (in my eyes) more widespread and stable. Problems with PHP 5.2 are more worrying, but as I said I have no idea what those changes may be as Marcus' email is pretty opaque. I'm guessing what you're talking about has something to do with one or both of these "todo" items listed on the link: # Drop ZE1 compatibility Done (marcus) # E_RECOVERABLE_ERROR Done (marcus, tony) but I still don't know what they really mean. Would you care to enlighten us?

---------- Forwarded message ---------- From: helly@php.net (Marcus Boerger) To: internals@lists.php.net Date: Sun, 14 May 2006 20:59:03 +0200 Subject: E_ALL changes in 5.2/6.0 Hello internals, by accident i added both E_STRICT and E_RECOVERABLE_ERROR to E_ALL while MFHing new features as discussed beforehand while decision was only to MFH E_RECOVERABLE_ERROR and not to put E_STRICT into E_ALL. See: http://oss.backendmedia.com/PhP52 Now the idea of E_STRICT is that core developers can inform users about changes in upcoming versions of php as early as possible. So developers should have E_ALL including E_STRICT enabled during development so that they are able to develop clean applications that most likely will work in the next version. On the production machines you would still either not use E_ALL or log only and don't show the errors in the application. That said i am about to not remove E_STRICT from E_ALL and MFH the php 6.0 to item just now. See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry)) Since this is for the benefit of the users to prevent issues with changes in behavior from my opinion it is best to do this behavior change as early as possible, which is in my opinion 5.2 anyway. That said i'll let it in and if there is no valid argument against, i will put it into the NEWS file and the newly started README.UPDATE_5_2. Best regards, Marcus -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- Justin Patrin