Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16760
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20050616111535.036020e0@localhost>
Date: Thu, 16 Jun 2005 11:18:02 -0700
To: boots <jayboots@yahoo.com>,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: andi@zend.com (Andi Gutmans)
References: <20050616163021.80366.qmail@web50807.mail.yahoo.com>

You missed the point of E_STRICT. I introduced it as an E_PEDANTIC. That 
was the whole idea. To be pedantic about code that works, not to warn about 
code that  doesn't work (which is for higher warning levels)

At 09:30 AM 6/16/2005 -0700, 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