Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25193
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Fri, 4 Aug 2006 09:23:57 +0200 (CEST)
To: Rasmus Lerdorf <rasmus@lerdorf.com>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <44D1FAF0.5060906@lerdorf.com>
Message-ID: <Pine.LNX.4.62.0608040908580.3704@localhost>
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>
  <44D0DB82.1070307@lerdorf.com>  <Pine.LNX.4.62.0608030933080.26373@localhost>
 <fe05d1540608030040s7f379e59g4b0449e63c10c0e6@mail.gmail.com>
 <44D1FAF0.5060906@lerdorf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness
From: derick@php.net (Derick Rethans)

On Thu, 3 Aug 2006, Rasmus Lerdorf wrote:

> Pierre wrote:
> > 
> > On 8/3/06, Derick Rethans <derick@php.net> wrote:
> > 
> > > > In this particular case I think it should be possible to mark 
> > > certain internal
> > > > methods as strict and keep userspace methods loose.
> > >
> > > But I would like to see atleast an e_strict warning of signatures are
> > > violated to give atleast the options to be strict and get warnings for
> > > it. I am pretty sure Edin doesn't give a **** about e_strict warnings...
> > > so that will work fine. I think that Zeev suggested something like this.
> > 
> > For what I understand (and agree), he meant the other way 'round.
> > Users who like strictness will have to use an extra keyword in the
> > declaration. Users who don't care will not have to change anything in
> > their (working) code.
> 
> I'm not all that keen on a new keyword for this.  How about using an interface
> to indicate strictness?  Isn't this really what interfaces are all about?

There is however a problem with this approach:

You would still need to modify code in order to get things "strict". 
Take for example some code that I have running (and want to keep 
running) on PHP 5.1. If in 5.2 we suddendly need to implement a specific 
interface in order to get strict behavior this code will no longer run 
on PHP 5.1 (without hacks). The other option is not to mark things as 
strict but that can makes things a bitch to debug. However, if we follow 
Zeev's proposal then there are no real problems at all - technical wise. 
Only having to ignore E_STRICT in case your apps are violating some core 
OO rules is then necessary. Splitting out E_STRICT into different error 
levels might work as well, but I am not so sure if that is necessary. So 
let me sum up the things from Zeev's proposal) and dropping his 4th 
point from it.

- 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

I think this is perfectly acceptable as it address both the people who 
want strictess, without having to change any code, and the people who do 
not care about it, which can simply ignore E_STRICT then.

regards,
Derick