Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25159
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7.0.1.0.2.20060803100857.086670d0@zend.com>
Date: Thu, 03 Aug 2006 10:11:22 +0300
To: ceo@l-i-e.com
Cc: internals@lists.php.net
In-Reply-To: <59598.67.108.68.40.1154555745.squirrel@www.l-i-e.com>
References: <EB.71.29121.B6690C44@pb1.pair.com>
 <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>
 <59598.67.108.68.40.1154555745.squirrel@www.l-i-e.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness
From: zeev@zend.com (Zeev Suraski)

At 00:55 03/08/2006, Richard Lynch wrote:
>On Wed, August 2, 2006 7:32 am, Zeev Suraski wrote:
> > I believe the problem is that 10 years ago we introduced what can be
> > described as 'loose OO programming', and we're replacing it (instead
> > of augmenting it) with strict OO programming.
>
>And there are people who actually LIKE the 'loose OO programming'
>paradigm.
>
>Presumably also some who don't really care, but who have significant
>bodies of code utilizing the 'looseness' who will simply refuse to
>upgrade to PHP 5 -- thus exacerbating the problem of PHP 4 sticking
>around for far longer than some would like.
>
>The suggestion for adding some kind of keyword to keep both camps
>happy seems reasonable, though I'm not sure I understood the details
>of the suggestion...
>
>To avoid breaking BC, it seems to me that:
>   E_ERROR is not issued without the extra keyword
>   E_STRICT, which is new anyway, is issued without the extra keyword
>
>So, it would seem, that the extra keyword should be 'loose' and would
>suppress the E_STRICT you would otherwise get.
>
>Example:
>class C {
>   function foo () {
>   }
>}
>
>class D extends C {
>   loose function foo ($a) {
>   }
>}
>
>class E extends C {
>   function foo ($a) {
>   }
>}
>
>E issues E_STRICT
>D does not issue E_STRICT
>
>At no time in a future release will E issue E_ERROR instead of
>E_STRICT -- This construct will remain in E_STRICT purgatory for all
>time.
>
>Purists who run under E_STRICT get their icky code flagged.
>Pragmatists who don't care can keep their same coding style.
>BC is not broken.
>
>Everybody's happy?

No, that means that the 'loose guys' (which just want their stuff to 
work) need to start going over their code and modify it.
Like I said, I don't think there's any need to add any new keyword in userland.
Instead - bad overriding will result in an E_STRICT, and it will be 
possible to tag internal functions so that it'll result in E_ERROR 
(in case it's really really bad that they're incorrectly 
overridden).  Pureness aside, it should make everyone happy from a 
practical point of view.

Zeev