Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25179
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <44D1C58F.8060209@iamjochem.com>
Date: Thu, 03 Aug 2006 11:44:47 +0200
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Lukas Smith <lsmith@php.net>
CC:  internals@lists.php.net,  pierre.php@gmail.com, 
 Zeev Suraski <zeev@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>	<44D0DB82.1070307@lerdorf.com>	<Pine.LNX.4.62.0608030933080.26373@localhost>	<fe05d1540608030040s7f379e59g4b0449e63c10c0e6@mail.gmail.com>	<7.0.1.0.2.20060803104541.0853b1e0@zend.com> <20060803095558.49c4e484@pierre-u64> <44D1B055.5070905@php.net>
In-Reply-To: <44D1B055.5070905@php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness
From: jochem@iamjochem.com (Jochem Maas)

Lukas Smith wrote:
> Hi,
> 
> well it seems that the initial vision of E_STRICT to denote future
> deprecation is no longer valid. Then again it might have been a
> misunderstanding from the beginning as E_DEPRECATED would have been the
> more obvious name in that case.

I did try to point this out but I was probably ignored due to lack of
karma (which is understandable given the volume of the thread).

I don't care much about *real* strictness issues but I do develop with
E_STRICT on because it tells me about things in my code that are depreciated
and/or will be removed in future versions (which is something I do care about).

so it seems an E_DEPRECIATED might be needed (requiring alot of E_STRICTS to
be changed), or alternatively something like an E_NOTRECOMMENDED?

someone just mentioned the the possibility of having this strictness
(and maybe others?) error be thrown as an E_NOTICE. I personally like this
approach because E_NOTICE does not have the same "this is second class code and
the ability to run it will disappear in the future" connotations as E_STRICT
does.

kind regards,
Jochem

> 
> I still think that a flag on a per class basis would be the better
> solution, but I guess I can accept this change.
> 
> This reminds me again about my question of how E_STRICT warnings are
> added and how things are then handled (E_STRICT becomes E_ERROR or the
> feature is removed entirely) with the future releases. I think a clear,
> written down policy is needed (and as always may be overwritten via
> common sense on a case by case basis).
> 
> regards,
> Lukas
>