Relax, I'm not debating the decision. Just:
PLEASE can someone put a big fat warning on the php 4.4 announcement on
www.php.net that it breaks existing code?
I already have people upgrading to it and wondering why they get tons
of warnings now. We're fixing them as quick as we can, but honestly,
given that PHP never gave us a notice about them before, there are
going to be a lot, and a lot in old releases too. It'd be helpful if on
the php side people were at least given a chance not to shoot
themselves in the foot.
-chuck
--
"But she goes not abroad in search of monsters to destroy." - John
Quincy Adams
Relax, I'm not debating the decision. Just:
PLEASE can someone put a big fat warning on the php 4.4 announcement on
www.php.net that it breaks existing code?I already have people upgrading to it and wondering why they get tons of
warnings now. We're fixing them as quick as we can, but honestly, given that
PHP never gave us a notice about them before, there are going to be a lot, and
a lot in old releases too. It'd be helpful if on the php side people were at
least given a chance not to shoot themselves in the foot.
They were already shooting them in the foot by using references wrong...
and you did have about a month to test your code (Horde I presume) with
the new PHP 4.4 release candidates. And it's just a notice... which you
should always have off on a production machine. So I don't think we
should put a BIG warning on php.net because people didn't quite
understand how references worked (me included).
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
On Tue, 12 Jul 2005 20:53:16 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:
Relax, I'm not debating the decision. Just:
PLEASE can someone put a big fat warning on the php 4.4
announcement on www.php.net that it breaks existing code?I already have people upgrading to it and wondering why they
get tons of warnings now. We're fixing them as quick as we can,
but honestly, given that PHP never gave us a notice about them
before, there are going to be a lot, and a lot in old releases
too. It'd be helpful if on the php side people were at least
given a chance not to shoot themselves in the foot.They were already shooting them in the foot by using references
wrong... and you did have about a month to test your code (Horde
I presume) with the new PHP 4.4 release candidates. And it's just
a notice... which you should always have off on a production
machine. So I don't think we should put a BIG warning on php.net
because people didn't quite understand how references worked (me
included).
The bug #33643 is not what I can call "shooting in my own foot".
There were cases were I fully agree to break BC, but this one and
its pairs, not. I agree that it's nice to solve this problem, my
point here is we fix a Zend bug by removing some facilities in the
langage. I only hope that we will allow that again in future
versions.
--Pierre
Pierre-Alain Joye wrote:
The bug #33643 is not what I can call "shooting in my own foot".
I'd call that precisely that, I had this happen in my own code a few
times, but looking at the code logically what was being done was clearly
wrong.
There were cases were I fully agree to break BC, but this one and
its pairs, not. I agree that it's nice to solve this problem, my
point here is we fix a Zend bug by removing some facilities in the
langage. I only hope that we will allow that again in future
versions.
In this case the "facility" was implementing, poorly might I add a
handler for a clearly incorrect behavior. Removing it was not only
appropriate but necessary to encourage proper code being written.
Ilia
Quoting Ilia Alshanetsky ilia@prohost.org:
In this case the "facility" was implementing, poorly might I add a
handler for a clearly incorrect behavior. Removing it was not only
appropriate but necessary to encourage proper code being written.
I know that other people have other points of view, but I am not
arguing this. I'm just asking that 4.4 be marked as having a non-BC
change, because - whether I could have updated my new code or not -
there's a ton of existing code out there that will never magically
change to run silently under 4.4.
I've already had people running old major versions of applications
upgrade to PHP 4.4 because it has "security fixes", and then come
complaining because suddenly they get a ton of warnings.
Yes, they could turn off warnings. But since the code has always run
cleanly beforehand, they don't think to do that.
Yes, they could very well ignore a note on php.net about the code
they're downloading.
But if there was a note with the 4.4 release, it would somewhat
lighten the load on PHP application developers dealing with the change.
-chuck
--
"But she goes not abroad in search of monsters to destroy." - John
Quincy Adams
Firstly, a major version number increment implies a major change (4.2.0
and 4.3.0 had much more major changes than this iirc). Secondly, as far
as I'm aware, it doesn't issue a warning, it issues notices which, and
this has been stressed on many occasions, should not be displayed on
production servers.
Lastly, there IS a note in the announcement stating that the major
version increase is due to a non-BC change, I don't see what everyone is
complaining about. Perhaps you should request that your users read what
they're downloading before they download it.
Just my thoughts.
Nicholas Telford
Chuck Hagenbuch wrote:
Quoting Ilia Alshanetsky ilia@prohost.org:
In this case the "facility" was implementing, poorly might I add a
handler for a clearly incorrect behavior. Removing it was not only
appropriate but necessary to encourage proper code being written.I know that other people have other points of view, but I am not arguing
this. I'm just asking that 4.4 be marked as having a non-BC change,
because - whether I could have updated my new code or not - there's a
ton of existing code out there that will never magically change to run
silently under 4.4.I've already had people running old major versions of applications
upgrade to PHP 4.4 because it has "security fixes", and then come
complaining because suddenly they get a ton of warnings.Yes, they could turn off warnings. But since the code has always run
cleanly beforehand, they don't think to do that.Yes, they could very well ignore a note on php.net about the code
they're downloading.But if there was a note with the 4.4 release, it would somewhat
lighten the load on PHP application developers dealing with the change.-chuck
Firstly, a major version number increment implies a major change (4.2.0
and 4.3.0 had much more major changes than this iirc). Secondly, as far
as I'm aware, it doesn't issue a warning, it issues notices which, and
this has been stressed on many occasions, should not be displayed on
production servers.
Sure, but the issue here has very little to do with production
servers.
What's happening is that site administrators are upgrading their test
environments and then checking their existing software to make sure it
hasn't broken. They see all of these new warnings and then report
them back to the application developers. It would be much easier for
each application developer to redirect that site administrators to a
note on php.net explaining the change than for the application
developers to explain the change over and over again. Or, even
better, the administrator would find it there themself.
--
Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/)
Or you as a developer add the following to your code:
error_reporting(error_reporting() & ~E_NOTICE);
at the top of a common file and release a new release and quit fing
b*ing about something which isn't likely to change anytime soon. If
your clients aren't knowledgeable enough to setup their servers
properly to not show errors in a production environment, then do it
for them in your script. Yeah it's not the best solution, but it works
fine and gives you time to correctly update your scripts the proper
way.
-Jeremy
Firstly, a major version number increment implies a major change (4.2.0
and 4.3.0 had much more major changes than this iirc). Secondly, as far
as I'm aware, it doesn't issue a warning, it issues notices which, and
this has been stressed on many occasions, should not be displayed on
production servers.Sure, but the issue here has very little to do with production
servers.What's happening is that site administrators are upgrading their test
environments and then checking their existing software to make sure it
hasn't broken. They see all of these new warnings and then report
them back to the application developers. It would be much easier for
each application developer to redirect that site administrators to a
note on php.net explaining the change than for the application
developers to explain the change over and over again. Or, even
better, the administrator would find it there themself.--
Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/)--
--
Jeremy Johnstone
http://www.jeremyjohnstone.com
jsjohnst@php.net
Yes, they could turn off warnings. But since the code has always run
cleanly beforehand, they don't think to do that.
It's definitely not the cleanest solution, but for those of you who
want to have a "quick fix" which will hide the problem until you have
time to fix it properly, use the following at the top of a common
file:
if(!defined('E_STRICT')) {
define('E_STRICT', 2048);
}
error_reporting(error_reporting() & ~E_NOTICE & ~E_STRICT);
Never depend on a user to do something for you that you can do
yourself. If you feel notice reporting should be off on a production
level script, then turn them off, and make it easy and documented for
them to turn it back on if they want it, not expect them to know how
to disable them theirself automatically.
--
Jeremy Johnstone
http://www.jeremyjohnstone.com
jsjohnst@php.net
Just for the record, most compilers have such "bugs". It happens when the
compiler is too lenient and allows incorrect code to be compiled. I've seen
similar things happen in C/C++ and other languages.
At 09:20 PM 7/12/2005 +0200, Pierre-Alain Joye wrote:
On Tue, 12 Jul 2005 20:53:16 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:Relax, I'm not debating the decision. Just:
PLEASE can someone put a big fat warning on the php 4.4
announcement on www.php.net that it breaks existing code?I already have people upgrading to it and wondering why they
get tons of warnings now. We're fixing them as quick as we can,
but honestly, given that PHP never gave us a notice about them
before, there are going to be a lot, and a lot in old releases
too. It'd be helpful if on the php side people were at least
given a chance not to shoot themselves in the foot.They were already shooting them in the foot by using references
wrong... and you did have about a month to test your code (Horde
I presume) with the new PHP 4.4 release candidates. And it's just
a notice... which you should always have off on a production
machine. So I don't think we should put a BIG warning on php.net
because people didn't quite understand how references worked (me
included).The bug #33643 is not what I can call "shooting in my own foot".
There were cases were I fully agree to break BC, but this one and
its pairs, not. I agree that it's nice to solve this problem, my
point here is we fix a Zend bug by removing some facilities in the
langage. I only hope that we will allow that again in future
versions.--Pierre
On Tue, 12 Jul 2005 13:04:36 -0700
andi@zend.com (Andi Gutmans) wrote:
Just for the record, most compilers have such "bugs". It happens
when the compiler is too lenient and allows incorrect code to be
compiled. I've seen similar things happen in C/C++ and other
languages.
Sure :) Was not bad meant. I prefer to see that fixed and work a
bit before to upgrade to 4.4 than having to deal with this bug :)
--Pierre