Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:32203 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62531 invoked by uid 1010); 10 Sep 2007 19:52:20 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 62516 invoked from network); 10 Sep 2007 19:52:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Sep 2007 19:52:20 -0000 Authentication-Results: pb1.pair.com smtp.mail=webmaster@keryx.se; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=webmaster@keryx.se; sender-id=pass Received-SPF: pass (pb1.pair.com: domain keryx.se designates 208.69.121.33 as permitted sender) X-PHP-List-Original-Sender: webmaster@keryx.se X-Host-Fingerprint: 208.69.121.33 supavet.nexcess.net Received: from [208.69.121.33] ([208.69.121.33:36114] helo=supavet.nexcess.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C3/40-59734-270A5E64 for ; Mon, 10 Sep 2007 15:52:20 -0400 Received: (qmail 22349 invoked by uid 108); 10 Sep 2007 19:52:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (gunther@keryx.se@87.227.57.139) by supavet.nexcess.net with ESMTPA; 10 Sep 2007 19:52:14 -0000 Message-ID: <46E5A06F.3000502@keryx.se> Date: Mon, 10 Sep 2007 21:52:15 +0200 User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: PHP Developers Mailing List References: <6F509818-65A2-4B17-8C44-6970E815A169@prohost.org> <46E45932.4090903@zend.com> <46E505B7.1090508@pooteeweet.org> In-Reply-To: <46E505B7.1090508@pooteeweet.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-1, 2007-09-10), Outbound message X-Antivirus-Status: Clean Subject: Re: [PHP-DEV] PHP 5.3 Suggested Feature List From: webmaster@keryx.se (Keryx Web) Lukas Kahwe Smith skrev: > Stanislav Malyshev wrote: > >>> 10) Split off deprecation from E_STRICT into E_DEPRECATED >> >> 0. Why do we *need* it again? > > Without it, we mix 2 different concepts, we also make it needlessly hard > for library maintainers to leverage E_STRICT. As a result library > maintainers have the choice of either jumping to every new minor version > as the minimum requirement or more or less ignoring E_STRICT all together. > Being a teacher who tries to explain PHP daily I am definately +1 on this one. Separating these two concepts really helps. Lars Gunther