Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25125
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <44D0A51D.2040701@iamjochem.com>
Date: Wed, 02 Aug 2006 15:14:05 +0200
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Zeev Suraski <zeev@zend.com>
CC: Lukas Smith <lsmith@php.net>,  internals@lists.php.net
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>
In-Reply-To: <7.0.1.0.2.20060802153423.0d046278@zend.com>
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)

Zeev Suraski wrote:

...

> 
> 
> My recommendation:
> - 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
> - Consider adding userland ability to set entire classes or methods as
> strict
> 
> Most people who use 'strict OO' will have E_STRICT enabled and have
> their code E_STRICT clean, so providing userland support for tagging
> classes/methods as strict is probably not really necessary.

one thing occur to me (from a enduser's POV):
E_STRICT is often used to denote usage that is depreciated and/or 'evil' with
the implication (when it's not explicitly mentioned) that in future one will
no longer be able to rely on the said usage. this makes, by implication,
anything that produces an E_STRICT is 'second class' which I believe is not
the implication that should be made here.

E_STRICT has seemingly been abused regarding it's meaning and it seems to
me that there is a need to differentiate between strictness and depreciation
(E_DEPRECIATED? E_EVIL?). I personally don't want to write/use code that is
depreciated [if I can help it] but mostly I don't give 2 hoots about strictness
(for instance, I'm quite disciplined enough to write matching method signatures
in relevant subclasses when that is needed; without php always forcing it upon me)

kind regards,
Jochem

PS - very nice to see someone come with up with a definite suggestion that does take
into account the voice of the [legion of?] php-nobodies who have concerns/issues
regarding the 'strictness' stuff that's been creeping in lately.

> 
> Zeev
>