Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26255
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.162.204 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:x-priority:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=GolTzaAofeaH0LU/SXDmXo+VzN6HPPpscZcHT9HrYemZp1A3JnU5I08SGiMzYAdJEkLC/AMwZhdbMcVbyeIJQhH6WeOJzB6R6o4wKEtFXpvF1j9Coqu3b+BuvxRCRIyUPGmGIjw+bn4wsAysp//l3WPhJMYBRf4iVr/Hepe4C0c=
In-Reply-To: <1838975922.20061024205524@marcus-boerger.de>
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> <E5728B60-0A7E-4E46-93AC-103A82CE44BD@prohost.org> <1838975922.20061024205524@marcus-boerger.de>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <71B5B01C-EDC5-46B0-8747-0706B2C7DF1F@prohost.org>
Cc: Zeev Suraski <zeev@zend.com>,
 Hannes Magnusson <hannes.magnusson@gmail.com>,
 php internals LIST <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Wed, 25 Oct 2006 16:35:09 -0400
To: Marcus Boerger <helly@php.net>
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)

Thanks to Hannes we have a fairly complete list of changes in the  
error conditions, so far people who have commented out it did not  
appear to have identified anything objectionable. We need to make a  
decision on how to proceed, either to roll 5.2.0 now or wait another  
week. My vote is to roll things now...


On 24-Oct-06, at 2:55 PM, Marcus Boerger wrote:

> Hello Ilia,
>
>   both, the __toString and the iterator in foreach by reference  
> would put
> the engine into an unstable state. That saiditis very important  
> that we do
> not blindley change error modes here. Most changes havebeen done  
> for a good
> reason. And most of those were added lately because we are always  
> pushing to
> fast with releases so that we only after releasing find out whatis  
> causing
> problems. And at that time peoplealready started to use those  
> 'features'
> andscream if we have to remove them. Just keep this in mind - please.
>
> best regards
> marcus
>
>
> Tuesday, October 24, 2006, 5:13:09 PM, you 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 <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
>
>
>
>
>
>
>
> Best regards,
>  Marcus
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Ilia Alshanetsky