My story:
Doing php since 1999 – running an IT company with several devs. Having about 200 sites (projects) out there. Having a web server farm with own projects as well as classical hosted sites not done by us on it.

I was able to switch from php 3 to php 4 and 5.

Now switching to 5.0.5 (A MINOR VERSION JUMP!!!) isn’t possible to me. It’s like committing suicide.

O.K. I can hear you saying: “I don’t understand why you use current() on a method – that’s ugly.” Well – nobody told me the last ~6 years!
I didn’t follow the internals list that much and I really didn’t look under php’s hood to see how this case is handled internally.
It seems that I started this ugly thing somewhere between 2003 and 2004 – well. I really thought that a thing that works without notice (all projects have E_ALL switched on) will work in the future (at least within a major version).

I can understand what Greg pointed out (as always).
But I’m really fed up when I read this theoretical “why did you ever do this ugly thing” blabla.

I will certainly not roll up 6 years of work to find every single case which leads to this problem. Why? Because I have to pay my monthly bills. Nobody will pay me for that AND – doing a current(Method) isn’t a BUG in my code which I HAVE to fix for my customers for free. Saying this is really ridiculous.

I think that we really need some kind of solution here.
And we need some kind of dialogue. The “this isn’t a bug – this is bogus – look into the changelog” thing isn’t the way to go.

return new Object();
is still perfectly valid. [...] Nico was wrong to suggest that
return new Foobar();
was invalid.

That’s incorrect. Since 4.4.0,

function &byRef() { return new Foo(); }

triggers one of the new kind of “Only variables can be returned…” notices – unless inside Foo()’s constructor $this is assigned by reference to something else. This is bogus, and the workaround “return $tmp =& new Foo()” is ridiculous. (bugs.php.net/33679)

Thanks for the clarification, that’s very encouraging to know. I’ve also run 4.4 without trouble myself with our software, so this one appears to not be an issue. We did have some BC issues with one of the 4.3.x series updates though, although we were able to resolve it fairly easily.

Cheers,

Lux

return new Object();

is still perfectly valid. The problem is:

return substr($foo,0,4);

You can return objects by reference. ONLY objects.

Nico was wrong to suggest that

return new Foobar();

was invalid.

I bought into the FUD about backward compatibility. Guess what? When I finally upgraded, not a single line of my code had a problem. And of all the third party apps, only squirrelmail had any problems and that was 1 line in each of 4 files.

How about having a process and a forum dedicated to the public review of major changes to PHP? “Major changes” would be new features, BC breaks, anything which would be of interest to more than a small minority of users.

http://bugs.php.net/bug.php?id=1991

That bug report is from 1999 acknowledging that they consider the above PHP statement to be valid back then. If so, then why is it suddenly sloppy coding, as some people on here are saying? I’ve been coding in PHP since about that time, and I expect code I wrote then for the 4.x series to continue to work now.

Grepping my project tree, I found 157 instances of the string “return new” both in my own code as well as in 3rd party packages we use. Perhaps that’s what caused on outcry of new users having strange problems recently that never happened before. BC is not just another nice-to-have, but the absolute most important thing to have. Several recent BC breaks in the PHP 4.3.x series have caused needless trouble for our customers, and I fear this may just be the cause of yet one more.

The people who say BC breaks need to stop are right. The only question that should be under discussion here is “how?” BC breaks should only ever be acceptable between *major* releases and with proper notice to developers. I have trouble enough with insidious BC breaks like the copy -> clone change from 4.x to 5.x, which means serious code review before we can declare PHP5 support, which is work which has zero value for us or our customers — ie. it’s a waste of time.

So I made a decision that our company won’t support PHP5 until we absolutely have to. Even compatibility mode — which can’t be turned on on a per-application basis, making it roughly useless for most of our would-be PHP5 users — isn’t 100% BC. This is a real issue with PHP, and it’s not flaming to say so. I’m glad somebody had the balls to say it. Cheers to them.

Written by Rasmus Lerdorf (14 Sep 02:25 comp.php.devel):

We have been looking to see if there is a way to fix the memory
corruption issue in a way that has less of an impact on existing code.
This doesn’t change the fact that every error you get is actually an
error in the code you are running. The broken code is effectively doing
something similar to:

function foo(&$arg) {
$arg = 4;
}
foo(strlen(”abc”));

which makes very little sense. There are many variations of this, but
in every instance it is something that should be fixed, and in some of
the cases it actually leads to memory corruption.

There are many examples of this sort of thing working just fine in PHP
4.3.x because people are passing things in by reference and never
modifying the passed in value. They’ll do something along the lines of:

function foo(&$arg) {
return $arg[0] + 1;
}
echo foo(array(1,2,3,4,5,6,7,8,9,10));

possibly because they believe that they are saving memory by not making
a copy of the array with that reference. Of course that is quite
misguided as no copy is done until the arg is modified so if you don’t
modify it, you are better off passing it by value.

Right now the change in 4.4 and 5.x is to complain loudly when you pass
a reference to something without any associated storage. In both of the
above examples there is no permanent storage associated with either of
the passed arguments, so trying to get a reference to this storage makes
very little sense. The only feasible way we might be able to work
around this is to make a copy of such bogus reference attempts and
effectively just pretend they were passed by value. I think it is a bit
of a hack, but at the same time the breakage of existing apps has been
more widespread than I think anybody anticipated. I’d still want to
throw a notice to let people know they are doing something odd though.

-Rasmus

Honestly, in this instance, I’d say it was the decision on the person to upgrade the entire live system’s fault. Granted, I think we’re talking theoretically, but even so. This event *should* never happen, although I’m sure it does.

Most web hosts are running php5 now. In fact, up until this recent fatal error, PHP 4 code ran on the PHP5 installations without issue.

I fully expect that very few people will upgrade to 5.0.5 from 5.0.4, but will upgrade instead directly to 5.1 when it ships and a better solution is in place for the problem (along with all the php4-only stragglers).

[quote]I would like to know what *exactly* is going to break my code.
Is there a place that discusses in more details what will and what won’t break (with examples)?[/quote]

The ONLY thing that will break will be in cases where you’re attempting to return something that IS NOT A VARIABLE by reference. Check the php-internals mailing list (it’s on the php.net site) for more details.