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 <[EMAIL PROTECTED]> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
