Grokbase › Groups › PHP › php-internals › November 2005
FAQ
Derick,
If you prefer a PHP which causes strange crashses and memory
corruptions, please downgrade to 4.3.11. I am getting tired
about this
bickering about this **FIX** that makes PHP stable.
You got me wrong here. I did not want to say anything against the 4.4.0
fix or even blame you for it.

But: nobody doubts that there has been a lot of public discussion about
it, that people were upset because they felt the language has been
changed in a way that caused them a lot of work and because their
scripts suddenly broke (and if only a by showing a warning or notice,
however).

I was only saying that you (i. e. the people who have enough karma to
make the final decisions here) should not light-heartedly make such a
change - and in this case, with no obvious need for it (apart from
cleaning up - I know myself that sometimes this is tempting for
developers).

As to the possible impact - I did a quick scan of Smarty and
phpDocumentor (because I used to have CVS HEAD checkouts of them at
hand) and found that both of them would be affected. Please, do not make
such a change that late in an RC5 and push it out with PHP5.1. At least
give the maintainers of popular PHP based projects some time to pick it
up and test it.

As with the 4.4.0, this is nothing you cannot fix or workaround or
suppress with an appropriate config. But once again the average user out
there might once again feel lost out there simply because his hoster did
the upgrade.

-mp.

Search Discussions

  • Greg Beaver at Nov 20, 2005 at 7:06 pm ⇧

    Matthias Pigulla wrote:
    As to the possible impact - I did a quick scan of Smarty and
    phpDocumentor (because I used to have CVS HEAD checkouts of them at
    hand) and found that both of them would be affected. Please, do not make
    such a change that late in an RC5 and push it out with PHP5.1. At least
    give the maintainers of popular PHP based projects some time to pick it
    up and test it.
    This is a non-issue for phpDocumentor. All we need is at least 6 months
    to a year of lead time on the final decision in order to adjust the code.

    However, it is obvious that a script is needed that iterates over a
    script and changes things that are easy to fix like the $a{blah} one. I
    have an idea for a callback-based php parser that might be able to solve
    this issue more easily, but it is just vaporware at the moment, as I
    need to learn a bit more of the PHP internals before being sure it is a
    practical idea.

    In the mean time, let's all calm down and note that the best thing to do
    is to take this course of action:

    1) assume things will be broken in PHP (X+1) - a major version increase
    means big changes by definition.
    2) be thankful this is transparent enough that we can have enough lead
    time to make small changes to legacy scripts as needed - this is why the
    E_STRICT is added to PHP 5.1 now. Would you prefer a sudden break in
    PHP 6 without any warning?
    3) ALWAYS test RCs of releases when they come out with our critical
    applications and note any breaks here, to determine whether they are
    bugs or intentional changes in PHP.

    Thanks,
    Greg

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedNov 20, '05 at 2:56p
activeNov 20, '05 at 7:06p
posts2
users2
websitephp.net

2 users in discussion

Matthias Pigulla: 1 post Greg Beaver: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase