[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pear-dev
Subject:    [PEAR-DEV] [Fwd: E_ALL changes in 5.2/6.0]
From:       Greg Beaver <cellog () php ! net>
Date:       2006-05-14 23:19:06
Message-ID: 4467BAEA.4040106 () php ! net
[Download message RAW]

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 :).

Thanks,
Greg

["E_ALL changes in 5.2/6.0" (message/rfc822)]

Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23342
Return-Path: <helly@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 3929 invoked by uid 1010); 14 May 2006 18:59:11 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 3914 invoked from network); 14 May 2006 18:59:11 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 14 May 2006 18:59:11 -0000
X-PHP-List-Original-Sender: helly@php.net
X-Host-Fingerprint: 81.169.182.136 ajaxatwork.net Linux 2.4/2.6
Received: from ([81.169.182.136:52461] helo=strato.aixcept.de)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id B8/32-19568-DFD77644 for <internals@lists.php.net>; Sun, 14 May 2006 14:59:09 -0400
Received: from baumbart.mbo (dslb-084-063-032-006.pools.arcor-ip.net [84.63.32.6])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by strato.aixcept.de (Postfix) with ESMTP id 0A1A735C1EC
	for <internals@lists.php.net>; Sun, 14 May 2006 20:59:05 +0200 (CEST)
Date: Sun, 14 May 2006 20:59:03 +0200
Reply-To: Marcus Boerger <helly@php.net>
X-Priority: 3 (Normal)
Message-ID: <138663365.20060514205903@marcus-boerger.de>
To: internals@lists.php.net
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: E_ALL changes in 5.2/6.0
From: helly@php.net (Marcus Boerger)

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

[prev in list] [next in list] [prev in thread] [next in thread]