Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24352
Return-Path: <lsmith@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 57236 invoked by uid 1010); 12 Jul 2006 17:34:09 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 57198 invoked from network); 12 Jul 2006 17:34:08 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 12 Jul 2006 17:34:08 -0000
X-Host-Fingerprint: 87.123.65.172 i577B41AC.versanet.de  
Received: from ([87.123.65.172:25407] helo=localhost.localdomain)
	by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP
	id 0F/C0-46743-0CB15B44 for <internals@lists.php.net>; Wed, 12 Jul 2006 11:56:49 -0400
Message-ID: <0F.C0.46743.0CB15B44@pb1.pair.com>
To: internals@lists.php.net
Date: Wed, 12 Jul 2006 17:56:44 +0200
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Posted-By: 87.123.65.172
Subject: E_STRICT
From: lsmith@php.net (Lukas Smith)

Hi,

PEAR is currently in the process of deciding from when on we want to 
mandate PHP5 as the target platform. Currently it looks like sometime in 
the next 3-6 months we will likely only accept PHP5 only packages.

We are also pondering how to best approach E_STRICT. It is not feasible 
for us to try to provide multiple packages per major version in order to 
keep up with new E_STRICT notices that might require features not yet 
available in previous versions.

Obviously one solution would be to disallow making anything an E_STRICT 
notice that is not available since the first release of the given major 
version. However I think that would defeat the purpose of E_STRICT.

Another solution would be to provide an easy way to filter out E_STRICT 
messages based on the version they have been introduced. This would 
enable a package developer to say "I want to be E_STRICT compatible upto 
PHP 5.1.4". Which would mean that he could filter out any E_STRICT 
notices that may for example get introduced in PHP 5.2.

Usually we slowly increase the lowest supported PHP version of packages 
in order to keep the code clean and fast, without pushing our users into 
a corner. So as the lowest supported PHP version increases, the 
filtering could be adapted.

Adding such a filter API into PHP internals however seems like a 
considerably effort. Therefore my proposal would be to simply add a 
defined "header" to all E_STRICT messages that contains the PHP version 
in which this E_STRICT message was added. This way PEAR could provide 
its developer with a simple filter method that would take an error 
message inside a customer error handler and determine if it should be 
filtered out or not.

What do you guys think?

regards,
Lukas