Re: Why 5.2 should not be delayed for E_DEPRECATED

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