Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25152
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <59598.67.108.68.40.1154555745.squirrel@www.l-i-e.com>
In-Reply-To: <7.0.1.0.2.20060802153119.0c2193c0@zend.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>
Date: Wed, 2 Aug 2006 16:55:45 -0500 (CDT)
To: internals@lists.php.net
Reply-To: ceo@l-i-e.com
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness
From: ceo@l-i-e.com ("Richard Lynch")

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?

This *seems* like a workable solution with not too terrible a price in
development, to this naive reader.

-- 
Like Music?
http://l-i-e.com/artists.htm