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.