I blogged about PHP 5 adoption in january when a survey put the adoption rate at 1.5%. I ran across a thread at web hosting talk, which asks Php5 rare, why? Bugs, backward compatibility problems, and the difficulty of running two versions at once come up as issues.
But I want to focus on backward compatibility problems. It looks like 5.1 is going to introduce some more backward compatibility issues. There have been several reports on the WACT mailing list that WACT doesn’t work under 5.1rc1. We traced it down to this statement:
$x =& $this;
Which results in “Fatal error: Cannot re-assign $this” under 5.1rc. (its fine in 4.x and 5.0)
Pavel from LIMB reported this as a bug, which was marked bogus. Later on, jayboots at sitepoint discovered that assigning to a instance variable instead of a local variable is allowed and offers a workaround:
$this->x =& $this; $x =& $this->x;
In a sitepoint thread about this issue, stereo frog adds:
They have a code in zend_compile.c that handles “$this=$x” and copy-pasted that code in the function that comples assignment by reference. This should prevent “$this=&$x” (which is wrong), but for some reason it “prevents” “$x=&$this” as well (which is absolutely correct).
I’m speculating that any type of intermediary would offer a work around. For example:
$temp = array('indirect' => &$this); $x =& $temp['indirect'];
I tried to verify this tonight, but I could not get 5.1rc to compile on my machine and I’ve run out of time to deal with that.
Two weeks ago, I tried to email the internals list to see if I could get an explanation, trying to determine if there was a valid reason for preventing $x =& $this, or if the bug was marked bogus by mistake. Unfortunately, I received no reply. 
I’m afraid that there are probably other BC breaks in 5.1. (Otherwise, its looking like a very nice release.)
Even more promising was some of the preliminary discussion around PHP 6.0.
In one web hosting forum that I visit, I was surprised to see how popular eAccellerator was for web hosts. There was discussion in a PHP 6.0 wishlist about possibly including a bytecode cache as standard issue. One benefit that I see to doing that is that is would act as a “get out of backward-compatibility jail free card.” The web hosts would probably be willing to slog through more BC issues if they had the direct payoff of a byte code cache. (Or force their customers to slog through them.) Perhaps we might see alot of web hosts move directly from php 4 to php 6?
After a byte-code cache, there is exactly one more “get out of BC jail free card” in the deck. That is a JIT compiler. On, that note, I’ll end with Java theory and practice: Urban performance legends, revisited.
Feed
Subscribe to this blog…
You itemize how screwed up the PHP5 release and how it’s just getting worse with 5.1, then segue with “Even more promising…” Wow.
PHP seems stuck right now. You know the problem of wanting to design for PHP5 but the reality of having to support PHP4. I don’t know if anything but time can solve it. Certainly the PHP Group are not doing anything but slowing th process down.
You guys don’t honestly believe that there will be a bytecode cache shipped standard with PHP anytime soon, do you? That is extremely unlikely to happen as long as Zend controls PHP development and offers a commercial bytecode cache. Zeev said in:
http://marc.theaimsgroup.com/?l=php-dev&m=112403105002697&w=2
“Need to think about that one.”
Which means “when pigs fly”. (You’ll notice how any serious discussion about the cache stopped at that point.)
Not trying to troll; I’m just saying if you’re holding your breath for a bundled cache now’s about the time to stop.
The use of $x =& $this is illegal because you can then do $x = new foo(); and then you replace the current object, which you should not be allowed to do.
[3 Oct 10:22am CEST] dmitry@php.net
Fixed in CVS HEAD and PHP_5_1.
PHP 5 lost it’s momentum and will probably never catch it again (perhaps PHP6 will have it better) .
BC is something where OS sucks big time and commercial software rulez.
I suppose you are talking about #34358. This bug has been reopened and assigned.
I agree that the error message is not that clear, but the problem ends in the same level as the one we had fixed in 5.0.5 or 4.4.0.
–Pierre
Nexen is now crediting about 4% of PHP 5, (here http://www.nexen.net/interview/index.php?id=50). I should have the october figures ready later this week.
I confirm that version evolution from 4.3.x to 4.3.x+1 gets usually 2 figure digits in a single month, while PHP 5 is still so low. PHP 5 is gaining very slowly everymonth.
BC breaks are not just OS problem, this is software reality, if you’ve ever been on a big software dev team when it comes time for a major version change of language/tools, stuff breaks *all* the time. Fact of life, get your change control processes in place, move on. I’ve seen it with Delphi and 3rd party apps, a team I worked on would test for months on a new version of delphi, quite a while after it was released, to make sure the entire code base would work, only then after changes etc made would it roll out to the entire team.
> The use of $x =& $this is illegal because you can then do $x = new
> foo(); and then you replace the current object, which you should
> not be allowed to do.
But i will never do $x = new foo();, that’s the problem! Why not throwing fatal when it actually happens?
>I’m afraid that there are probably other BC breaks in 5.1.
That means only that you need to start testing it before it gets out.
But I’m afraid that *nobody* of those people that talk about “slowing down”, “stuck”, “more BC breaks to come” etc. really care about it, most of them only want to talk.
Obviously PHP Group is unable to test RCs with each and every piece of existing software to check BC, so it’s time for you to start caring about *your code* and its status with the upcoming releases.
If you mean talk as in bring it to people’s attention (say by filing a bug report, posting to internals and blogging about it) before the final release rather than bitch about it afterwards, yup, thats what I want to do.
[...] Following up on the Backward compatibilty and web host adoption of PHP 5 post from two weeks ago, I got a pretty good education about the problem with taking a reference of $this. The best summary is in this bug report. [...]