Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:26233 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33785 invoked by uid 1010); 24 Oct 2006 15:18:21 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 33770 invoked from network); 24 Oct 2006 15:18:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Oct 2006 15:18:21 -0000 Authentication-Results: pb1.pair.com smtp.mail=zeev@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=zeev@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender) X-PHP-List-Original-Sender: zeev@zend.com X-Host-Fingerprint: 212.25.124.162 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from [212.25.124.162] ([212.25.124.162:43457] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F3/73-30135-ABE2E354 for ; Tue, 24 Oct 2006 11:18:21 -0400 Received: (qmail 9642 invoked from network); 24 Oct 2006 15:16:51 -0000 Received: from localhost (HELO zeev-notebook.zend.com) (127.0.0.1) by localhost with SMTP; 24 Oct 2006 15:16:51 -0000 Message-ID: <7.0.1.0.2.20061024171800.05845960@zend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 24 Oct 2006 17:18:06 +0200 To: Ilia Alshanetsky Cc: "Hannes Magnusson" , "php internals LIST" , "Marcus Boerger" In-Reply-To: References: <7.0.1.0.2.20061024085428.053f9cf8@zend.com> <7f3ed2c30610240757v28702861r8d5f22f7e3047e60@mail.gmail.com> <7.0.1.0.2.20061024170856.0583dd20@zend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PHP-DEV] Why 5.2 should not be delayed for E_DEPRECATED From: zeev@zend.com (Zeev Suraski) Right. Zeev At 17:13 24/10/2006, Ilia Alshanetsky wrote: >Some OO errors like using iterators by reference and throwing >exceptions out of __toString() are ligit as well, doing so would/ >could cause problems. > > >On 24-Oct-06, at 11:10 AM, Zeev Suraski wrote: > >>I think that a lot of those are legit - we only need to 'demote' >>the language-level warnings/errors that attempt to enforce strict >>OO standards. >>Warnings/errors that warn about unacceptable input are legitimate >>and should stay. >> >>Zeev >> >>At 16:57 24/10/2006, Hannes Magnusson wrote: >>>On 10/24/06, Ilia Alshanetsky wrote: >>>>Zeev, >>>> >>>>There are probably 5-6 new fatal errors in the engine since 5.1, >>>>some >>>>of which cannot be delegated to lower error reporting modes as they >>>>may cause engine instability or similar problems. Rasmus was >>>>going to >>>>make a list of all the newly added engine error changes, hopefully >>>>he'll have that list soon. >>> >>>Attached is a list (php examples) over all the backwards incompatible >>>error throwing I could find... >>>-Hannes >>> >>> >>> >>>> >>>> >>>>On 24-Oct-06, at 2:55 AM, Zeev Suraski wrote: >>>> >>>> > Ilia, >>>> > >>>> > I think Wez's suggestion is the most practical one. Let's make >>>> > sure we haven't introduced any fatal errors into 5.2 (and demote >>>> > them to E_STRICT for now), and handle the rest of the suggestions >>>> > afterwards. >>>> > >>>> > Zeev >>>> > >>>> > At 02:33 24/10/2006, Ilia Alshanetsky wrote: >>>> >> I've been reading people's replies to Marcus' RFC in regard to >>>> >> E_DEPRECATED and it seems that some people have expressed the >>>>want to >>>> >> delay 5.2 until mucking around with error handling is done one >>>>way or >>>> >> another. My simple answer to this is no. >>>> >> >>>> >> The long answer is as follows. >>>> >> >>>> >> PHP 5.2.0 is not the last 5.X release, there will be more >>>>patch level >>>> >> versions and at the very least at least one more major >>>>version, so we >>>> >> should not be trying to stuff every single feature under the sun >>>> >> into it as if it was the end of the 5 series. Furthermore, it >>>>makes >>>> >> little sense to make drastic error handling changes this late >>>>in the >>>> >> game, rushing the decision process and possibly excluding >>>>developers >>>> >> who do not read the list every day or are currently away. It >>>>should >>>> >> go through an extensive peer review and comment process, be >>>>tested, >>>> >> tried with real applications to see what breaks and so on, >>>>this is >>>> >> not a trivial change. Another words it is too major of a >>>>change to do >>>> >> at the last minute, rushing it will only lead to problems we'd >>>>end up >>>> >> cleaning up for many more releases to come. We also need to >>>>remember >>>> >> that 5.2 is already way behind schedule, which is important >>>>because >>>> >> it contains a fair number of security fixes, without which a good >>>> >> number of users are vulnerable to a variety of exploits. >>>>Delaying the >>>> >> release means not deploying those fixes and in my opinion is a >>>> >> disservice to all users of PHP. >>>> >> >>>> >> In my opinion we need to make a release, continue considering >>>> >> Marcus' RFC, develop a patch and push it to our real >>>>development tree >>>> >> PHP 6.0. If it proves to be solid and does not break (m)any >>>> >> applications it would be the first candidate to back-port to 5 >>>>series >>>> >> once 5.3 is under consideration. >>>> >> >>>> >> >>>> >> Ilia Alshanetsky >>>> >> >>>> >> -- >>>> >> PHP Internals - PHP Runtime Development Mailing List >>>> >> To unsubscribe, visit: http://www.php.net/unsub.php >>>> > >>>> > -- >>>> > PHP Internals - PHP Runtime Development Mailing List >>>> > To unsubscribe, visit: http://www.php.net/unsub.php >>>> > >>>> > >>>> >>>>Ilia Alshanetsky >>>> >>>>-- >>>>PHP Internals - PHP Runtime Development Mailing List >>>>To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >>>Content-Type: text/plain; >>>name="backwards.incompatible.error.throwing.txt" >>>Content-Disposition: attachment; >>>filename="backwards.incompatible.error.throwing.txt" >>>X-Attachment-Id: f_etof8h3u >> > >Ilia Alshanetsky > > >