I say 5.1.2 because it looks like there are is going to be at least one, possibly two bug fix releases to follow. There is a bit of a kerfuffle about the introduction of a date class into PHP 5.1rc6, which conflicts with the current PEAR date class. Unfortunately, the naming conflict is not (yet) documented in the upgrade notes which I praised in my PHP 6 post just a couple of days ago.

Ok, so reserving common class names in the release candidate just before the release, during a major holiday week (in the US at least) is probably a mistake. I don’t disagree with PHP reserving the Date class. Honestly, anyone using that name should half expect it. However, I don’t think anyone likes surprises, especially late in a release cycle. But, people are not machines and sometimes mistakes are made. (To use another cliche, sometimes sausage making is not pretty.)

After the Reference compatibility thing I thought there was supposed to be a process in place to catch surprises like this. What happened?

Some people are pointing to this naming conflict as evidence of the dire need for namespace support in PHP. Fair enough.

So in this case the process for detecting backward compatibility breaks relied on a large group of people testing their applications through a rapid succession of release candidates. Since I agree with the rapid succession of release candidates, I have to see the weak part of the process as relying on people to test stuff. After all, people aren’t machines.

However, machines ARE machines and automated compatibility testing could have caught this. I have a corpus of PHP code with automated tests that I could donate to a BC testing lab. I’m sure other people do. I can’t necessarily download a new release candidate and run it every other day, but I could package my code up and send it someplace to be run. Where can I send it?

(Yeah, I know calling for BC testing lab without volunteering to run it is the open source equivalent of the unfunded mandate. But hey, its my blog and I’ll suggest, complain or critique if I want to. )

One last thing, don’t let a few minor issues overshadow the good hard work that went into this release.

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;
 

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.