Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25133
Return-Path: <robert@interjinn.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 63636 invoked by uid 1010); 2 Aug 2006 15:14:04 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 63620 invoked from network); 2 Aug 2006 15:14:04 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 2 Aug 2006 15:14:04 -0000
X-PHP-List-Original-Sender: robert@interjinn.com
X-Host-Fingerprint: 66.11.173.122 unknown Linux 2.5 (sometimes 2.4) (4)
Received: from ([66.11.173.122:37969] helo=blobule.interjinn.com)
	by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP
	id E3/3B-45114-C31C0D44 for <internals@lists.php.net>; Wed, 02 Aug 2006 11:14:04 -0400
Received: by blobule.interjinn.com (Postfix, from userid 2000)
	id CBCFB5ACE3D; Wed,  2 Aug 2006 11:19:14 -0400 (EDT)
To: Derick Rethans <derick@php.net>
Cc: Zeev Suraski <zeev@zend.com>, Lukas Smith <lsmith@php.net>,  internals@lists.php.net
In-Reply-To: <Pine.LNX.4.62.0608021454380.26373@localhost>
References: <EB.71.29121.B6690C44@pb1.pair.com>
	 <18810497049.20060801234124@marcus-boerger.de>
	 <1154478748.6599.16.camel@blobule>
	 <Pine.LNX.4.62.0608020940590.26373@localhost>
	 <E9.41.45114.FFB50D44@pb1.pair.com>
	 <Pine.LNX.4.62.0608021138530.26373@localhost>
	 <16.85.45114.FF370D44@pb1.pair.com>
	 <7.0.1.0.2.20060802153423.0d046278@zend.com>
	 <Pine.LNX.4.62.0608021454380.26373@localhost>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: InterJinn
Date: Wed, 02 Aug 2006 11:19:14 -0400
Message-ID: <1154531954.3034.24.camel@blobule>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.1 
Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness
From: robert@interjinn.com (Robert Cummings)

On Wed, 2006-08-02 at 16:07 +0200, Derick Rethans wrote:
> On Wed, 2 Aug 2006, Zeev Suraski wrote:
> 
> > My recommendation:
> > - Add a new flag to methods (at the implementation level) that will allow to
> > flag them as 'strict'
> 
> Have an example of what you mean here?

Maybe something like the following...

<?

class foo
{
    function bleh( $p1, $p2 )
    {
        echo "Bleh: $p1, $p2\n";
    }
}

class fee extends foo
{
    loose function bleh( $p1 )
    {
        parent::bleh( $p1, $this->prop );
    }
}

?>

I think I like it :D In this case, no E_STRICT would be issued since we
specifically declared it as loose. if no "loose" declaration had been
added then as Zeev suggested an E_STRICT would be issued. If a "strict"
declaration was added then an E_ERROR would be issued. This would
provide backwards compatibility with an E_STRICT hit, and forward
compatibility without the E_STRICT hit so that your code doesn't look
erroneous. I think E_STRICT should enforce PHP rules, not OOP rules, so
in that sense no E_STRICT would be fired since the code follows the
rules of PHP development. Someone correct me if that is not PHPs
intended use of E_STRICT.

Cheers,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'