Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26210
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain proposaltech.com from 66.51.199.86 cause and error)
To: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <453D3C1D.4040707@php.net>
References: <1485570655.20061023210857@marcus-boerger.de>
	 <Pine.LNX.4.62.0610232124440.30333@localhost>  <453D3C1D.4040707@php.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Mon, 23 Oct 2006 16:12:15 -0700
Message-ID: <1161645135.7371.48.camel@notebook.local>
Mime-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] E_STRICT/E_DEPRECATED
From: truth@proposaltech.com (Todd Ruth)

I'm not a voter, but I'd like to lobby for a fancier
E_STRICT...

E_STRICT is sounding more and more like runtime "lint".
I very much miss lint.  (I'm sure it's still around, but 
I've been programming in only php for the last few years.)
A key feature of lint that made it usable was that you
could have a file listing error codes that you always 
wanted to ignore and you could use a comment adjacent to
your "bad" code to tell lint to ignore that specific
case.  I think a previous thread talked about using codes
in the messages to allow easy bulk filtering, so the
file of codes to skip isn't absolutely necessary.  Being
able to put in a comment that causes the E_STRICT to
be skipped for an adjacent bit of "bad" code would be
very friendly.  We make sure all of our code is NOTICE
free (for as many code paths as we can stand to test)
before it goes out the door.  I'm sure many others do
the same.  To be able to do the same with E_STRICT would
be a great benefit, but I think a larger portion of the
user base would adopt it if there were ways to turn down
the volume when you really want to ignore "the guidelines
for ideal code".  I have no idea how difficult such a
feature would be; I just wanted to point out how useful
it would be.  (As always, thanks for all that all of you
do!)

BTW, the trend on the list toward separating STRICT
and DEPRECATED and only putting deadly stuff in the
DEPRECATED bin is very much appreciated.  For a while
I was guessing we'd never be able to upgrade our php!
I'm still assuming 5.2 is unusable based on the threads
about fatal errors, but it seems all this will be sorted
out for 5.3 at the latest.  That's better than being
on 5.1 for the rest of our lives.

Thanks,
Todd