On the SitePoint PHP blog today Bruno Skvorc has written about the PHP 7 revolution and some of the changes coming with this next major version of the language (including return types and the removal of some functionality).

With the planned date for PHP 7's release rapidly approaching, the internals group is hard at work trying to fix our beloved language as much as possible by both removing artifacts and adding some long desired features. There are many RFCs we could study and discuss, but in this post, I'd like to focus on three that grabbed my attention.

He touches on a few topics in the post including:

the debate that came up about PHP 5.7 versus PHP 7

The addition of return types from functions/methods

The removal of PHP4 style constructors

Changes to the extension API

Obviously, since PHP7 is no where near release status, all or some of these things could be subject to change. For example, the removal of PHP4 constructors is still being hotly contested on the php.internals mailing list at the time of this post.

Tony Marston has posted a plea to the core developers of the PHP language when it comes to some of the changes happening with constructors in classes: "please do not break our language."

This post is addressed to PHP's core developers who are proposing to break our beloved language yet again in the next major version of PHP (version 7) by removing functionality which has worked perfectly for years simply because it does not fit in with their ideas of how it should be done today. I am talking about PHP RFC: Remove PHP 4 Constructors (and this post on php.internals) which proposes that all code with PHP 4 style constructors be made invalid in favour of the "correct" method which was introduced in PHP 5. This is despite the fact that both types of constructor have lived quite happily side by side for over a decade and that large volumes of code, including PEAR libraries, were written in the PHP 4 style.

He suggests that this kind of change would require quite a bit of code to be changed, causing headaches for a large audience out there using older PHP code. He then gets into some of his opinions and thoughts about who "owns" PHP - is it the core development team working on the language itself, the community that uses the language (or a combination of both)? He proposes two definitions of "improvement" in respect to the needs of developers using the language and core developers. He suggests that the core developers are changing the language "just because they can" and that breaking backwards compatibility with something like this is a big mistake.

He then shares some of the comments from the php.internals mailing list on the subject of the constructor change, both for and against. He also points out a few other places where backwards compatibility was broken and the resulting changes that had to be made by developers. He suggests a "if it ain't broke, don't fix it" kind of approach

If there is a choice between a lazy or incompetent core developer doing only half a job and leaving the 240 million members of the greater PHP community to clear up his mess, then it should be obvious to anyone who has more than two brain cells to rub together that it is the core developer who needs to put in the extra effort so that the greater PHP community does not have to.

According to a new post to the CodeIgniter.com blog, there's been even more changes in the 2.0 version of the framework - including dropping PHP4 support all together.

A few days ago a new repository popped up on our internal Mercurial server. We're not particularly creative with our naming, so it was simply CodeIgniterNoPhp4. [...] With only a handful of significant changes to its codebase, the release was pushed along. We want to make CI 2 worth its name, so starting today, we're requiring PHP 5.1.6 on our master branch.

They include a few things to watch out for including naming conventions, the change to __construct, a cleaner model object interface and chaining added to the email and validation libraries.

There's some huge news from the WordPress blog today - an end of life announcement that the popular blogging platform will no longer be supporting PHP4 and MySQL 4.

Our approach with WordPress has always been to make it run on common server configurations. We want users to have flexibility when choosing a host for their precious content. Because of this strategy, WordPress runs pretty much anywhere. Web hosting platforms, however, change over time, and we occasionally are able to reevaluate some of the requirements for running WordPress. Now is one of those times. You probably guessed it from the title '" we're finally ready to announce the end of support for PHP 4 and MySQL 4!

The last version that will fully support PHP4 will be v3.1 and will be released in late 2010. The next version (v3.2) will jump the requirement up to PHP 5.2. According to their statistics, only around 10% of the installs are on PHP4. They also found that less than 6% of users were on MySQL 4. See the full post for complete details.

Andrew Nacin, one of the core developers of WordPress, has a recent post to his blog about the current state of PHP and how that relates to WordPress' backwards compatibility support of PHP4.

I've been meaning to write this post nearly a month now, on the heels of WordPress 3.0′s release and preparing for an inevitable future discussion of when we should drop PHP 4 support. And then current events give you the hook you need to sit down and do it.

He talks about WordPress 3.0, the support of PHP Earthlink offered, how their PHP4 usage stands currently, efforts they've done to get people to make the move up from PHP4 versions, PHP5 market penetration and more.

In this new post to his blog till argues his case for PEAR and why support for PHP4 is a good thing when it comes to making things "just work."

Every once in someone likes to argue that PEAR is all fugly PHP4 code and why you should not use it, and instead go and use another framework or component library. Most of those people also say that they looked at or used PEAR x years ago and then act all surprised when someone else disagrees.

He talks about some of the rules around the major/minor PEAR releases and backwards compatibility breaks which, thankfully, a lot of other projects seem to adhere to. He points out that some packages have been started for different PHP generations (Mail_Queue2 vs Mail_Queue) and a few reasons why the PHP4 EON doesn't automatically mean PEAR should follow suit.

In a new post to his blog today, Brandon Savage talks about the "fade time" for PHP4 and how, really, it's gone on long enough.

Sadly, developing for PHP 4 backwards compatibility is something that companies and individuals are still doing. Wordpress released a new Widget API in version 2.8 that relies on the old-style PHP 4 constructor. Apparently, for Wordpress and many other developers, wide adoption is more important than language improvements.

This all came about because he noticed the Log PEAR package still supported PHP4. He's been making updates, though, to bring it out of the shadows and into the light of PHP5-only support.

Still, I look forward to the day when PHP 4 finally does go away forever, leaving us with a much better code base and happier developers.

The Zend Developer Zone has a new article that will interest developers still looking to make the jump from PHP4 to PHP5 (you know who you are) with Informix support. Zend Core can help.

There are many business web applications written in PHP4 that use the Informix module for data access. PHP4 is no longer supported and as a result will not be issued any more fixes or releases. Since version 5.2, the Informix module is no longer available for the PDO module. In this article I'll to describe how to compile and install the Informix module on the Zend Core 2.5 (PHP 5.2.6)

The tutorial helps you set up your environment and build/install the Informix module to be plugged into the Zend Core stack. Activation is as simple as going into the Zend Core admin tool and enabling the extension. A sample script is included to test the results.

Its also noted in the comments that there's a PDO driver for Informix that can be pulled from the PECL extension repository.

Sebastian Bergmann has posted a real world benchmark as justification for moving from a PHP 4 to PHP 5 environment - evidence from Flickr's change.

Benchmarks such as the PHP / GCC / ICC Benchmark I posted quite a while ago on this blog are synthetic. They test "raw bytecode execution" speed that cannot be translated into real-world situations per se. Flickr recently migrated from PHP 4 to PHP 5. And here are their real world numbers.

The graph shows a dramatic drop in processing needed (CPU usage) at the moment they made the switch over from PHP4 to PHP5.The system processing usage stayed about the same (system processes like logging and memory handling) but the user CPU usage (like what the web server would use) saw an immediate change by almost twenty percent.