Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:25182 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85018 invoked by uid 1010); 3 Aug 2006 10:28:02 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 84995 invoked from network); 3 Aug 2006 10:28:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Aug 2006 10:28:02 -0000 X-Host-Fingerprint: 195.225.34.5 fw01.axit.nl Received: from ([195.225.34.5:18819] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP id B1/E5-44390-CFAC1D44 for ; Thu, 03 Aug 2006 06:07:58 -0400 Message-ID: To: internals@lists.php.net 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> <44D1B055.5070905@php.net> <44D1C58F.8060209@iamjochem.com> Date: Thu, 3 Aug 2006 12:07:09 +0200 Lines: 66 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2869 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Posted-By: 195.225.34.5 Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness From: r.korving@xit.nl ("Ron Korving") I think this is all going way too far. If one wants a "loose" class, you'll just have to suppress errors? That just doesn't sound right. It's like having a feature, but the system telling you "don't use it! it's bad!". If anything, I think E_NOTICE would be much better than E_STRICT, which only seems to be an option because the not-loose classes are called "strict" classes. Still, I think triggering errors/notices/whatevers just sounds wrong. People want to code clean with all messages visible, And want to use (or not use) this loose feature that's being discussed. I would never dream of using a feature that triggers error messages, and so the feature isn't viable for me (and a lot of other people). - Ron "Jochem Maas" schreef in bericht news:44D1C58F.8060209@iamjochem.com... > Lukas Smith wrote: >> 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 did try to point this out but I was probably ignored due to lack of > karma (which is understandable given the volume of the thread). > > I don't care much about *real* strictness issues but I do develop with > E_STRICT on because it tells me about things in my code that are > depreciated > and/or will be removed in future versions (which is something I do care > about). > > so it seems an E_DEPRECIATED might be needed (requiring alot of E_STRICTS > to > be changed), or alternatively something like an E_NOTRECOMMENDED? > > someone just mentioned the the possibility of having this strictness > (and maybe others?) error be thrown as an E_NOTICE. I personally like this > approach because E_NOTICE does not have the same "this is second class > code and > the ability to run it will disappear in the future" connotations as > E_STRICT > does. > > kind regards, > Jochem > >> >> 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 >>