Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:25167 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37319 invoked by uid 1010); 3 Aug 2006 08:14:23 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 37304 invoked from network); 3 Aug 2006 08:14:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Aug 2006 08:14:23 -0000 X-Host-Fingerprint: 87.123.83.197 i577B53C5.versanet.de Received: from ([87.123.83.197:27771] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP id CE/60-44390-D50B1D44 for ; Thu, 03 Aug 2006 04:14:22 -0400 To: internals@lists.php.net, pierre.php@gmail.com Message-ID: <44D1B055.5070905@php.net> Date: Thu, 03 Aug 2006 10:14:13 +0200 User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 CC: Zeev Suraski References: <18810497049.20060801234124@marcus-boerger.de> <44CFDB2B.1010907@cschneid.com> <20060802010156.5be0258c@pierre-u64> <44CFDF89.6010506@lerdorf.com> <7.0.1.0.2.20060802153119.0c2193c0@zend.com> <44D0DB82.1070307@lerdorf.com> <7.0.1.0.2.20060803104541.0853b1e0@zend.com> <20060803095558.49c4e484@pierre-u64> In-Reply-To: <20060803095558.49c4e484@pierre-u64> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 87.123.83.197 Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness From: lsmith@php.net (Lukas Smith) Hi, well it seems that the initial vision of E_STRICT to denote future deprecation is no longer valid. Then again it might have been a misunderstanding from the beginning as E_DEPRECATED would have been the more obvious name in that case. I still think that a flag on a per class basis would be the better solution, but I guess I can accept this change. This reminds me again about my question of how E_STRICT warnings are added and how things are then handled (E_STRICT becomes E_ERROR or the feature is removed entirely) with the future releases. I think a clear, written down policy is needed (and as always may be overwritten via common sense on a case by case basis). regards, Lukas