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 <[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
Best regards,
Marcus
--
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
