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.

It comes down to the fact that allowing references to be taken of $this can lead to unexpected values for $this later on. ($this re-assigned) However, it does not appear that a good solution exists:

Given the choice between: (A) doing nothing but leaving room for confusion, (B) taking away the ability to create references, or (C) checking assignments for references to $this(read: slow); The current decision is to go with (A).

The cause of the problems were a result of diverging away from strategy A and a little bit into strategy B. I’m still working on compiling 5.1rc3, so i’m not yet sure how this was actually resolved. I wouldn’t feel bad about a warning when this occurred. However, I think a fatal error is absolutely wrong here. I do feel confident this will get resolved in an acceptable manner because I’m fairly sure that unless it becomes illegal to pass $this to a function by reference that there will always be a workaround for making code compatible with PHP 4 regarding $this. Thanks to everyone who looked in to it.

In the meantime, Derrick Rethans made an article he wrote for php|architect explaining PHP References available. You should read this article. I had to print it to follow it, but I learned something that I did not know. I did not know that PHP uses a copy on write semantic for normal variables. The one question that I wish the article had covered was how objects get automatically passed by reference in PHP 5.

The article debunks some myths about using references for performance. I experimented with this a bit when PHP 4 first came out, but quickly gave up on using references for optimization. I ended up with too many mysterious bugs to track down from “magically connected” variables. I finally ended with some fairly limited rules for using references. I avoid them in all cases except when passing values to functions by reference and for variables that held objects, in which case I use them always. When I want mystery i’ll go to the library, thank you. I don’t need it in my software.

I’ve been looking at the changes necessary for the php 4.4/5.0.5 update. I wrote a little scanner program to help locate suspicious return statements. (I’m far from E_STRICT anyway.) But, I have no programatic help for finding “Only variables can be passed by reference” errors except to actually trigger the error.

I’ve been a little bit frustrated about getting over the compatibility hump with 4.4/5.0.5/5.1rc3. But that seems like nothing compared to the ingrate who emailed Derrick fan mail. This dude needs to get a grip.

I don’t think the update was a mistake at all. Like I said earlier, I’ll take my PHP without mysterious bugs, please. Rather, I think the mistake here was in not understanding the backward compatibility issues. I went back and read some of the orginal discussion about this update. What strikes me was that binary compatibility was discussed, but no-one seemed that excited about the backward compatibility issues at the code level.

So a mistake was made. These things happen. Steps have been taken to ensure that something like this is less likely happen again. Derrick’s fan needs to get over it and move on.

Along these lines, It seems like with so many projects using automated testing that there should be a process for projects with automated test suites to package them up and donate them to an automated backward compatibility lab.