Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26232
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.162.207 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=FMLWb1F6tDDWNssz1uYCin5hTHbxs9eqScCN8qCtsaJ2xaDdNAjfZSyXBkaa0v7TtxvinAFfiYgM/9Iho0ZXaH+OkLYMm/72ElqomgigZTQEPa8XHxL1xyanL1hqaS4d3IW88Ua7xt3PTQvoVW/O3x6+Tr7om5lW3FRcSWhZZpQ=
In-Reply-To: <7.0.1.0.2.20061024170856.0583dd20@zend.com>
References: <A302A34A-2257-447B-A2A0-CD665F80DC47@prohost.org> <7.0.1.0.2.20061024085428.053f9cf8@zend.com> <F2137416-B788-4C8F-80C5-FEC0AFCD31D2@prohost.org> <7f3ed2c30610240757v28702861r8d5f22f7e3047e60@mail.gmail.com> <7.0.1.0.2.20061024170856.0583dd20@zend.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <E5728B60-0A7E-4E46-93AC-103A82CE44BD@prohost.org>
Cc: "Hannes Magnusson" <hannes.magnusson@gmail.com>,
 "php internals LIST" <internals@lists.php.net>,
 "Marcus Boerger" <helly@php.net>
Content-Transfer-Encoding: 7bit
Date: Tue, 24 Oct 2006 11:13:09 -0400
To: Zeev Suraski <zeev@zend.com>
Sender: Ilia Alshanetsky <iliaal@gmail.com>
Subject: Re: [PHP-DEV] Why 5.2 should not be delayed for E_DEPRECATED
From: ilia@prohost.org (Ilia Alshanetsky)

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 <ilia@prohost.org> 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