# php 4.4 BC break

- Thread: https://externals.io/message/17242
- Original archive: https://news-web.php.net/php.internals/17242
- Started by Chuck Hagenbuch on 2005-07-12T14:52:34+00:00
- Messages: 11
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #17242 — Chuck Hagenbuch — 2005-07-12T14:52:34+00:00

URL: https://externals.io/message/17242#17242

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

---

## #17243 — Derick Rethans — 2005-07-12T18:53:16+00:00

URL: https://externals.io/message/17242#17243 · In reply to: #17242

> 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

---

## #17244 — Pierre-Alain Joye — 2005-07-12T19:20:26+00:00

URL: https://externals.io/message/17242#17244 · In reply to: #17243

On Tue, 12 Jul 2005 20:53:16 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:

> 
> 
> > […]
> 
> 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

---

## #17245 — Andi Gutmans — 2005-07-12T20:04:36+00:00

URL: https://externals.io/message/17242#17245 · In reply to: #17243

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:
>
> > […]
>
>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

---

## #17246 — Ilia Alshanetsky — 2005-07-12T20:12:32+00:00

URL: https://externals.io/message/17242#17246 · In reply to: #17244

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

---

## #17247 — Pierre-Alain Joye — 2005-07-12T20:16:07+00:00

URL: https://externals.io/message/17242#17247 · In reply to: #17245

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

---

## #17248 — Chuck Hagenbuch — 2005-07-12T20:17:03+00:00

URL: https://externals.io/message/17242#17248 · In reply to: #17246

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

---

## #17249 — Nicholas Telford — 2005-07-12T21:33:14+00:00

URL: https://externals.io/message/17242#17249 · In reply to: #17248

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>:
> 
> > […]
> 
> 
> 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

---

## #17251 — Jeremy Johnstone — 2005-07-13T03:17:21+00:00

URL: https://externals.io/message/17242#17251 · In reply to: #17248

> 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

---

## #17288 — Jon Parise — 2005-07-17T20:07:00+00:00

URL: https://externals.io/message/17242#17288 · In reply to: #17249

> 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/)

---

## #17331 — Jeremy Johnstone — 2005-07-20T01:37:47+00:00

URL: https://externals.io/message/17242#17331 · In reply to: #17288

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 f***ing
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


> 
> 
> > […]
> 
> 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