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
Ilia Alshanetsky wrote:
I've been reading people's replies to Marcus' RFC in regard to
E_DEPRECATEDand 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.
SIMPLE QUESTION - I've just been through the exercise of finally moving
everything to 5.1.6 after testing everything. I'd dropped back to 5.0.4
simply because 5.0.5 cause problems with nearly all of my sites and
could not be used. Are any of the 'rule changes' in 5.2 going to cause
the same compatibility problems as 5.0.5 did - if so and E_DEPRECATED is
the correct state for these changes then it needs sorting before release
rather than once again releasing code that just causes problems.
At the very least we need a proper statement of what could be broken
rather than the comments buried somewhere in the release notes ?
--
Lester Caine - G8HFL
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
For this particular purpose there is a fairly detailed
README.UPDATE_5_2 that details the major functionality changes that
have happened in PHP 5.2
Ilia Alshanetsky wrote:
I've been reading people's replies to Marcus' RFC in regard to
E_DEPRECATEDand 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.SIMPLE QUESTION - I've just been through the exercise of finally
moving everything to 5.1.6 after testing everything. I'd dropped
back to 5.0.4 simply because 5.0.5 cause problems with nearly all
of my sites and could not be used. Are any of the 'rule changes' in
5.2 going to cause the same compatibility problems as 5.0.5 did -
if so andE_DEPRECATEDis the correct state for these changes then
it needs sorting before release rather than once again releasing
code that just causes problems.At the very least we need a proper statement of what could be
broken rather than the comments buried somewhere in the release
notes ?--
Lester Caine - G8HFLL.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop - http://home.lsces.co.uk/
ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/
index.php--
Ilia Alshanetsky
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
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_STRICTfor now), and handle the rest of the suggestions afterwards.
+1
I guess this is the best we can go. It might cause some trouble for
people developing in E_STRICT, but I also think that 5.2.0 really needs
to be in the hands of users.
regards,
Lukas
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.
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 toE_STRICTfor 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_DEPRECATEDand 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
--
--
Ilia Alshanetsky
Ilia Alshanetsky 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.
It's 7:30am here. Hold your horses. I have a couple of meetings this
morning and will get to it after those.
-Rasmus
Well I'm definitely not referring to those, only the new strict OO
fatals as per Marcus's original message...
Zeev
At 16:32 24/10/2006, Ilia Alshanetsky 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.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 toE_STRICTfor 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
--
--
Ilia Alshanetsky
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
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 toE_STRICTfor 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_DEPRECATEDand 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
--
--
Ilia Alshanetsky
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:
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...
-HannesIlia,
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 toE_STRICTfor 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_DEPRECATEDand 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
--
--
Ilia Alshanetsky
--
Content-Type: text/plain; name="backwards.incompatible.error.throwing.txt"
Content-Disposition: attachment;
filename="backwards.incompatible.error.throwing.txt"
X-Attachment-Id: f_etof8h3u
Some OO errors like using iterators by reference and throwing
exceptions out of __toString() are ligit as well, doing so would/
could cause problems.
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:
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...
-HannesIlia,
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 toE_STRICTfor 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_DEPRECATEDand 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
--
--
Ilia Alshanetsky
--
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
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.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:
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...
-HannesIlia,
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 toE_STRICTfor 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_DEPRECATEDand 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
--
--
Ilia Alshanetsky
--
Content-Type: text/plain;
name="backwards.incompatible.error.throwing.txt"
Content-Disposition: attachment;
filename="backwards.incompatible.error.throwing.txt"
X-Attachment-Id: f_etof8h3uIlia Alshanetsky
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.
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:
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...
-HannesIlia,
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 toE_STRICTfor 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_DEPRECATEDand 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
--
--
Ilia Alshanetsky
--
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
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...
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
marcusTuesday, 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.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:
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...
-HannesIlia,
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 toE_STRICTfor 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_DEPRECATEDand 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
--
--
Ilia Alshanetsky
--
Content-Type: text/plain;
name="backwards.incompatible.error.throwing.txt"
Content-Disposition: attachment;
filename="backwards.incompatible.error.throwing.txt"
X-Attachment-Id: f_etof8h3uIlia Alshanetsky
Best regards,
Marcus--
Ilia Alshanetsky
Ilia Alshanetsky wrote:
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...
Out of curiosity What's the plan for E_DEPRECATED now?
Regarding the release of PHP 5.2 and OO strictness:
I never got any comment about my OO strictness patch to not complain
about adding default values to parameters or changes on static methods
which both do not break the quoted
http://en.wikipedia.org/wiki/Liskov_substitution_principle
I would have hoped for a little info why this patch was not considered.
Regards,
- Chris
Hello Christian,
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP. Actually in PHP static methods are inherited as any
other method (also true for a lot of other languages). Now given Liskov
rules you can as well add default parameter values as add new parameters
with default values and even change type hints (when respecting the rules
correctly). With C++ the first language has proven that changing default
parameter values is a bad idea. There however mainly because they are bound
at compile time based on the compile time types, which results in default
values that are mostly not what you would expect. In PHP it might work as
expected but then all programmers that come from langiages like C++ get
confused. Also it would disallow a few optimizer things later (going the C++
way of compile time function invocatoin binding). The same holds for new
additional parameters. In most languages that is no option because it would
effectively be a different function. In PHP it would eventually work but add
more confusion that it would help. The last point, changing type hints in
derived class' methods, was discussed at PDM and declined. The main reason
for that decision were that all languages we knew of do not support it and
that most people even do not understand the rules which are quite the
opposite of what most people think.
However the point of adding E_DEPRECATED is still open. Where open only
means which version will first have it. From my perspective that will be
either 5.3.0 or 6.0.0 depending on whetever comes out first. Helping here
would be greatly appreciated.
best regards
marcus
Friday, November 3, 2006, 4:31:52 PM, you wrote:
Ilia Alshanetsky wrote:
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...
Out of curiosity What's the plan for
E_DEPRECATEDnow?
Regarding the release of PHP 5.2 and OO strictness:
I never got any comment about my OO strictness patch to not complain
about adding default values to parameters or changes on static methods
which both do not break the quoted
http://en.wikipedia.org/wiki/Liskov_substitution_principle
I would have hoped for a little info why this patch was not considered.
Regards,
- Chris
Best regards,
Marcus
Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP.
This is common in PHP and you consider this good practice? Interesting,
wasn't what I would have expected...
Now given Liskov
rules you can as well add default parameter values as add new parameters
with default values
...
In PHP it might work as
expected but then all programmers that come from langiages like C++ get
confused.
I didn't realized how big an impact C++ has on the PHP design. Allow me
to shudder, I'm glad we're only talking E_STRICT here (-:C
However the point of adding
E_DEPRECATEDis still open. Where open only
means which version will first have it. From my perspective that will be
either 5.3.0 or 6.0.0 depending on whetever comes out first. Helping here
would be greatly appreciated.
What help is needed, compiling the list of E_NOTICE/E_STRICT to be
convert to E_DEPRECATED? Or giving input on how to convert the
individual messages? I'm willing to help.
Regards,
- Chris
Hello Christian,
Saturday, November 4, 2006, 5:13:32 PM, you wrote:
Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP.
This is common in PHP and you consider this good practice? Interesting,
wasn't what I would have expected...
I didn't say it is good practice, god behave :-)
In PHP it might work as
expected but then all programmers that come from langiages like C++ get
confused.
I didn't realized how big an impact C++ has on the PHP design. Allow me
to shudder, I'm glad we're only talkingE_STRICThere (-:C
Pretty long explanation but I hope it clearifies how I was answering:
Language developers copy from each other. Copy in the sense of looking
at the ideas and experience from others and taking them over, in a
fashion that suites their own language. As PHP has a C like syntax and
also some C semantics it goes in a pool with languages like C, C++, C#,
ObjC, Java and a few more. It also has influence from Perl or Delphi.
Looking at the object model we have, it is a combination of influences
from C++, Java and Delphi plus lately also C#. Plus stuff I cannot even
specify a counterpart for, maybe some of Python. So when I mention C++
here, I am refering to a specific piece of behavior that can best be
found in C++. And I would do the same for other parts with the help of
other Languages. I do so becasue I consider that most people prefer an
explantion by example over a theoretical explanation - in that case I
can suggest nice books:
- Object-Oriented Type Systems by Jens Palsberg and Michael I Schwartzbach
http://www.amazon.com/Object-Oriented-Type-Systems-Jens-Palsberg/dp/047194128X/sr=1-1/qid=1162662320/ref=sr_1_1/002-5762121-6939211?ie=UTF8&s=books - A Theory of Object by Martin Abadi and Luca Cardelli
http://www.amazon.com/Theory-Objects-Monographs-Computer-Science/dp/0387947752/sr=1-1/qid=1162662574/ref=sr_1_1/002-5762121-6939211?ie=UTF8&s=books
Actually the first book is pretty easy and can get anybody started. The
second is a pretty mathematical approach. That is very good, since it
shows what you can do and what not and can explain why certain things
are not working. But in PHP we don't respect much of the rules. Unless
E_STRICTis active, which gets the most imortant ones. Luca Cardelli
wrote more about the Lambda Calculus but I haven't read them since the
book above captures all that's needed.
However the point of adding
E_DEPRECATEDis still open. Where open only
means which version will first have it. From my perspective that will be
either 5.3.0 or 6.0.0 depending on whetever comes out first. Helping here
would be greatly appreciated.
What help is needed, compiling the list of E_NOTICE/E_STRICT to be
convert to E_DEPRECATED? Or giving input on how to convert the
individual messages? I'm willing to help.
Yes such a list would be very helpfull. If you think individual messages
need to be altered other then changing the severity than we might need to
discuss that as well. Having the list of such messages would help anyway.
Because without helpfull feedback we can never get rid of design flaws.
Looking forward to get that list.
best regards
marcus
Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP.This is common in PHP and you consider this good practice? Interesting,
wasn't what I would have expected...I didn't say it is good practice, god behave :-)
So you're adding a warning to something useful (factory methods) to help
people doing something dubious? ;-)
Language developers copy from each other. Copy in the sense of looking
at the ideas and experience from others and taking them over, in a
fashion that suites their own language. As PHP has a C like syntax and
Just make sure you don't fall into the trap of not seeing the great
potential PHP has because it is different from the other languages.
PLEASE NOTE: I don't expect you to reply to the above points as my email
is just meant as food for thought and we're discussing language design
philosophy here which would take too much space with little hope of
getting to an agreement. But that's ok, I accept your opinion and you're
much more in charge of PHP than I am.
What help is needed, compiling the list of E_NOTICE/E_STRICT to be
convert to E_DEPRECATED? Or giving input on how to convert the
individual messages? I'm willing to help.Yes such a list would be very helpfull. If you think individual messages
need to be altered other then changing the severity than we might need to
discuss that as well. Having the list of such messages would help anyway.
I don't consider the text of the messages itself as that crucial.
I attached a little script which greps for error types and outputs a
file to quickly visit those places in the source files.
Hope this helps,
- Chris
Liskov applies to static methods as soon as calls via objects are
common
which is true for PHP. Actually in PHP static methods are inherited as
any
other method (also true for a lot of other languages). Now given Liskov
rules you can as well add default parameter values as add new
parameters
with default values and even change type hints (when respecting the
rules
correctly). With C++ the first language has proven that changing
default
parameter values is a bad idea. There however mainly because they are
bound
at compile time based on the compile time types, which results in
default
values that are mostly not what you would expect. In PHP it might work
as
expected but then all programmers that come from langiages like C++ get
confused. Also it would disallow a few optimizer things later (going
the C++
way of compile time function invocatoin binding). The same holds for
new
additional parameters. In most languages that is no option because it
would
effectively be a different function. In PHP it would eventually work
but add
more confusion that it would help. The last point, changing type hints
in
derived class' methods, was discussed at PDM and declined. The main
reason
for that decision were that all languages we knew of do not support it
and
that most people even do not understand the rules which are quite the
opposite of what most people think.
Hi Marcus,
Enlightening explanation in a long and confusing thread.
To restate the last point for clarification, if the PHP's rules were
following Liskov's rules, this
php -d"error_reporting=8191" -r 'class Foo {} class FooBar extends Foo
{} class T {function f(FooBar $x){}} class S extends T {function f(Foo
$x){}}'
and possibly
php -d"error_reporting=8191" -r 'class T {function f(StdClass $x){}}
class S extends T {function f($x){}}'
would not be E_STRICT violations as they currently are. In both
examples the subclass weakens the parent classes' preconditions (type
hints). So PHP's E_STRICT rules are (intentionally) 'stricter' than
Liskov's rules.
Best Regards,
Jeff
Hello Jeff,
Sunday, November 5, 2006, 7:09:26 PM, you wrote:
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP. Actually in PHP static methods are inherited as any
other method (also true for a lot of other languages). Now given Liskov
rules you can as well add default parameter values as add new parameters
with default values and even change type hints (when respecting the rules
correctly). With C++ the first language has proven that changing default
parameter values is a bad idea. There however mainly because they are bound
at compile time based on the compile time types, which results in default
values that are mostly not what you would expect. In PHP it might work as
expected but then all programmers that come from langiages like C++ get
confused. Also it would disallow a few optimizer things later (going the C++
way of compile time function invocatoin binding). The same holds for new
additional parameters. In most languages that is no option because it would
effectively be a different function. In PHP it would eventually work but add
more confusion that it would help. The last point, changing type hints in
derived class' methods, was discussed at PDM and declined. The main reason
for that decision were that all languages we knew of do not support it and
that most people even do not understand the rules which are quite the
opposite of what most people think.
Hi Marcus,
Enlightening explanation in a long and confusing thread.
To restate the last point for clarification, if the PHP's rules were
following Liskov's rules, this
php -d"error_reporting=8191" -r 'class Foo {} class FooBar extends Foo
{} class T {function f(FooBar $x){}} class S extends T {function f(Foo
$x){}}'
and possibly
php -d"error_reporting=8191" -r 'class T {function f(StdClass $x){}}
class S extends T {function f($x){}}'
would not be
E_STRICTviolations as they currently are. In both
examples the subclass weakens the parent classes' preconditions (type
hints). So PHP'sE_STRICTrules are (intentionally) 'stricter' than
Liskov's rules.
Yes, both above are correct for Liskov and Lambda Calculus however it
is the opposite of what most people expect. Thus we decided against it
last year. So in PHP the typehint has to be as in the root class.
Best regards,
Marcus
In PHP it might work
as
expected but then all programmers that come from langiages like C++
get
confused.
I'm sorry, but, really, I'm not interested in crippling PHP to cater
to C++ converts... :-) :-) :-)
I don't think this is a particularly strong point for you to make.
I believe PHP stands on its own as its own merits, and forcing it to
conform to some way C++ behaves, especially an artifact of the
"compile" phase of C++, is just not a Good Idea.
Also it would disallow a few optimizer things later (going
the C++
way of compile time function invocatoin binding).
Just this morning I was thinking that PHP would be better off
following the Lisp #. model rather than the C++ borg-like model.
In Lisp, if you want something computed at compile-time, and you
agree to it being a 'constant' after that, you can wrap it in a #.
construct:
#.( [expression] )
as I recall.
For example:
set_cookie("oatmeal", "raisin", time() + #.(6060243652), '/');
#.() gives the first-pass compiler the option to compute that value
immediately, substitute in the result, and use it as a CONSTANT from
that point forward.
Obviously we could not use #.() syntax -- That's just an example.
But it could be useful in PHP for all kinds of stuff, particularly in
tight loops.
Of course, something as simple as:
define('ME', $_SYSTEM['PHP_SELF']);
define('MAX_COOKIE_TIME', 6060243652);
might be a lot easier and just as useful :-)
Last time I checked, though, you couldn't do that...
In PHP it would eventually work
but add
more confusion that it would help.
Really?
Because I find myself more and more confused by the PHP OOP model's
continued restrictions and syntax and behaviour every few months than
I am by it NOT behaving like PHP.
It's like I'm in some Twilight Zone where PHP is being taken over by
C++/Java borg that doesn't actually like PHP as it is. [shrug]
The PHP OOP model behaves less and less like PHP and more and more
like all the other languages I choose not to use.
As much as I prefer PHP 5 OOP referencing over the PHP 4 copy mess,
the rest of it is quickly becoming a lot of baggage I don't really
want to deal with.
I've been too badly burned in the past by private/protected morass in
large-scale projects from somebody else's code I can't change without
all kinds of problems.
Every time you guys lock something else down and force it to work your
way instead of leaving it up to the Developer, I'm counting on it
biting me on the butt a few years from now. That's just the way it
works. :-v
However the point of adding
E_DEPRECATEDis still open. Where open
only
means which version will first have it. From my perspective that will
be
either 5.3.0 or 6.0.0 depending on whetever comes out first. Helping
here
would be greatly appreciated.
I honestly belive that 6.0.0 is the Right Answer, as it will change
the way too many things work from 5.2 to 5.3, as things stand now, as
I understand it...
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?