Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16743
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20050616195027.0366c130@localhost>
Date: Thu, 16 Jun 2005 19:51:55 +0300
To: boots <jayboots@yahoo.com>
Cc: internals@lists.php.net
In-Reply-To: <20050616163021.80366.qmail@web50807.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] In regards to E_STRICT and PHP5
From: zeev@zend.com (Zeev Suraski)
References: <20050616163021.80366.qmail@web50807.mail.yahoo.com>

Why would you enable it then?  You have to very explicitly enable it, as 
it's off by default, and doesn't get enabled even if you switch to E_ALL.

I think it can help, and I don't see how it can hurt given the fact it's 
not on unless you want it to.

Zeev


At 19:30 16/06/2005, boots wrote:
>I was hoping that in the future, E_STRICT wasn't expanded and was
>perhaps even taken back a step. I understand the reason for it: code
>correctness. Yet if PHP5 is (rightly) considered a runtime engine then
>its job should be to evaluate and execute code and in the case of
>failure, explain why it could not do so. In other words, if a code
>segment is valid, then the runtime should just do its job and run that
>code. Code correctness is the job for offline tools like lint. Yes, PHP
>is a dynamic language so things like E_NOTICE are often required to be
>triggered by the runtime. Yet the only place keywords can be generated
>dynamically is through an eval -- and I suggest that getting deprecated
>warnings at that point is not very enlightening. There is another
>difference between an E_NOTICE and a deprecated warning: the first can
>lead to (or mask) programming errors, the second can not. Its almost as
>if another error flag (not error level) was needed, something like
>E_DEPRECATED. The real question is, should the runtime be concerned
>about that or should that be something that the toolchain handles? I
>would rather the latter.
>
>If there is any merit to E_STRICT as it stands currently I find it to
>be negated by the fact that it throws messages for completely
>acceptable code that the engine is both willing and capable of
>handling. If var is not acceptable, I think it should be removed as a
>keyword. If it is acceptable, the engine shouldn't complain about it.
>(of course, I think it is acceptable.)
>
>Very best regards and thanks.
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php