I’ve also been impressed with the new upgrade notes for 5.1. Good job there, too.

I’ve read over the whole thing and I like what I see. One thing did jump out at me.

We also discussed whether we should even allow Unicode mode to be turned off as current micro benchmarks show that the Unicode implementations of some of the string functions are up to 300% slower, and whole applications up to 25% slower. Disallowing Unicode mode to be turned off is expected to slow down the adoption of PHP 6 too as many ISPs would be reluctant to install a version that immediately slows down the applications of their users.

I am definitely not familiar with all the issues involved, but wouldn’t this make it hard to write general purpose PHP applications? Programs would have to check whether unicode was on or off? Wouldn’t that checking be slow and complicated, too?

I think its great to discuss ways to improve adoption of PHP 6 so far ahead. It looks like APC will be included. I think thats great news on the adoption front.

I wonder, though, if anyone has gone and asked hosting companies what features they might like to see in PHP 6? I also wonder if it would be helpful to have two upgrade guides: one for programmers and one for hosts. Perhaps even a separate Hosting PHP Applications section as part of the PHP manual. (With things like “How do I find out which PHP script sent out this spam?”)

PHP hosting concerns are not always the same as PHP programmer concerns. Hosts are important to the adoption of PHP and throwing them some love can only be a good thing for the platform as a whole.

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.