Everything

php

php 4.4 BC break

php.internals

Chuck Hagenbuch

21 years ago

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

Derick Rethans

21 years ago

On Tue, 12 Jul 2005, Chuck Hagenbuch 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).

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Pierre-Alain Joye

21 years ago

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

> On Tue, 12 Jul 2005, Chuck Hagenbuch 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

Ilia A.

21 years ago

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

Chuck Hagenbuch

21 years ago

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

Nicholas Telford

21 years ago

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:

Jon Parise

21 years ago

On Tue, Jul 12, 2005 at 10:33:14PM +0100, Nicholas Telford wrote:

> 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

21 years ago

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

On 7/17/05, Jon Parise <jon@php.net> wrote:

> On Tue, Jul 12, 2005 at 10:33:14PM +0100, Nicholas Telford wrote:
>
> > 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/)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
---------------------------
Jeremy Johnstone
http://www.jeremyjohnstone.com
jsjohnst@php.net

Zeev Suraski

21 years ago

At 00:33 13/07/2005, Nicholas Telford wrote:

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

That's the thing, though.  4.4.0 was not pitched as a major release.  It
was, and still is, pitched as a bugfix release.  Quoting php.net:

"he increased middle digit was required because the fix that corrected the
problem with references changed PHP's internal API. PHP 4.4.0 does not have
any new features, and is solely a bugfix release."

The average user, or even fairly informed user, should have no reason to
guess that he should be auditing his code because he installed a bugfix
release.

>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.

Sorry for nitpicking, but no type of errors, whether they're warnings,
notices or fatal errors, should be displayed on production systems.  I
don't see a real difference between warnings and notices, it depends
primarily on the type of developer, rather than the stage of the
application.  Some developers, such as myself - would not be willing to
deploy code that is not 'E_NOTICE complaint', and would clean E_NOTICEs
just as much as E_WARNINGs.  They'd log them or display them in exactly the
same way.

>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.

Wrong, read the announcement again.  It mentions the internal API.  It
gives nobody any reason to even remotely suspect that their code needs to
be altered in order to be complaint.

Zeev

Ron Korving

21 years ago

> >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.
>
> Wrong, read the announcement again.  It mentions the internal API.  It
> gives nobody any reason to even remotely suspect that their code needs to
> be altered in order to be complaint.
>
> Zeev

You are right. And a lot of people are gonna be pretty pissed off after
upgrading their production servers. Luckily I was able to stop someone from
doing just that, because he didn't know about this BC-break, and after
checking into it, he concluded 4.4 would break a lot of his software.

It doesn't matter how wrong the programmers were by abusing PHP in this way.
You have to feel sympathy for the fact that these people will be upgrading
their servers only to find out their code stops working. How big a deal is
it to announce this properly? I don't get it.. It would be a very easy task,
and it would save a lot of people a lot of time and annoyance. I really
don't understand where this ignorance and unwillingness to inform the users
come from.

Ron

Derick Rethans

21 years ago

On Sat, 16 Jul 2005, Ron Korving wrote:

> It doesn't matter how wrong the programmers were by abusing PHP in this way.
> You have to feel sympathy for the fact that these people will be upgrading
> their servers only to find out their code stops working.

It doesn't "stop working", you just get a friendly notice saying that
you're doing something wrong.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Ron Korving

21 years ago

I wonder how friendly they will find this notice showing up :) (I know most
of the people out there won't have PHP set up to show notices, but what
counts for most people, doesn't automatically count for all people)

"Derick Rethans" <derick@php.net> wrote in message
news:Pine.LNX.4.62.0507161107120.17601@localhost...

> On Sat, 16 Jul 2005, Ron Korving wrote:
>
> > It doesn't matter how wrong the programmers were by abusing PHP in this

way.

> > You have to feel sympathy for the fact that these people will be

upgrading

David Zülke

21 years ago

error_reporting/display_errors should be disabled on production environments
anyway, so where's the problem. And on dev machines, people will finally
realize they did something stupid. It's up to them to fix it or not to fix
it.

- David

Jeremy Johnstone

21 years ago

On 7/12/05, Chuck Hagenbuch <chuck@horde.org> wrote:

> 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

Andi Gutmans

21 years ago

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:

Pierre-Alain Joye

21 years ago

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