Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:25135 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 79483 invoked by uid 1010); 2 Aug 2006 15:44:03 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 79465 invoked from network); 2 Aug 2006 15:44:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Aug 2006 15:44:03 -0000 X-PHP-List-Original-Sender: truth@proposaltech.com X-Host-Fingerprint: 68.142.198.208 smtp109.sbc.mail.mud.yahoo.com Received: from ([68.142.198.208:29014] helo=smtp109.sbc.mail.mud.yahoo.com) by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP id 5F/7D-45114-048C0D44 for ; Wed, 02 Aug 2006 11:44:02 -0400 Received: (qmail 34186 invoked from network); 2 Aug 2006 15:43:54 -0000 Received: from unknown (HELO ?192.168.2.106?) (toddruth@sbcglobal.net@69.230.17.37 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 2 Aug 2006 15:43:53 -0000 Reply-To: truth@proposaltech.com To: internals@lists.php.net In-Reply-To: <7.0.1.0.2.20060802153423.0d046278@zend.com> References: <18810497049.20060801234124@marcus-boerger.de> <1154478748.6599.16.camel@blobule> <16.85.45114.FF370D44@pb1.pair.com> <7.0.1.0.2.20060802153423.0d046278@zend.com> Content-Type: text/plain Date: Wed, 02 Aug 2006 08:44:09 -0700 Message-ID: <1154533449.25510.24.camel@notebook.local> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness From: truth@proposaltech.com (Todd Ruth) Hooray! Thank you, Zeev! I'd nearly given up hope on ever moving to a new version of php. (Actually, I'm still doomed for using $this in static calls to an unrelated class, but every bit of avoiding fatal errors helps.) Our code may not be OO, but it's definitely php. ;) Thanks, Todd On Wed, 2006-08-02 at 15:43 +0300, Zeev Suraski wrote: > My recommendation: > - Add a new flag to methods (at the implementation level) that will > allow to flag them as 'strict' > - In case such a strict method is improperly overridden - error out (E_ERROR) > - In case a non-strict method is improperly overridden - emit E_STRICT > - Consider adding userland ability to set entire classes or methods as strict > > Most people who use 'strict OO' will have E_STRICT enabled and have > their code E_STRICT clean, so providing userland support for tagging > classes/methods as strict is probably not really necessary. > > Zeev