Top 10 PHP 5.4 features to vote

Contents

The status of PHP 5.4

Top 10 PHP 5.4 features being voted

Other features that may be voted and the PHP fork

The new voting process

PHP 5.4 Alpha 1 release date

Conclusions

The status of PHP 5.4

PHP 5.4 is really coming as we discussed in last month's episode of Lately in PHP podcast. This release is managed by the PHP core developers Stas Malishev and David Soria Parra. It is not a trivial job for them but they are committed to take care of all the steps necessary to make PHP 5.4 happen.

As I mentioned before, now it is the turn to vote on features that may not be consensual. The voting process is coming one month later than originally expected, but it is really moving on.

Top 10 PHP 5.4 features being voted

The first thing to decide is which features will be included in PHP 5.4. Therefore Stas Malishev posted a message in the PHP internals list letting everybody know about the PHP 5.4 features to be voted.

This is just an initial proposal of features to get everybody inline with what is going to be voted. There is an initial list of 10 proposals.

More features may be included as long as there is complete RFC proposal document, or a patch that can be readied in no more than one month. Old proposals may also be considered if the original proponents are still interested to push them for PHP 5.4 and they are available to implement the features.

For now let me just give an overview of the initial 10 proposals. I have marked each one with +1 and -1 to show clearly whether I think each of the proposals are good ideas or not.

1. PHP/php reserved namespace name (+1)

PHP 5.3 introduced namespaces but there was no definition of which namespaces names could be used. This proposal is meant to prevent that anybody redefines the PHP namespace, which is to be reserved for PHP built-in functions, classes, constants, etc.. It seems to be a good idea.

4. Drop magic quotes (+1)

Magic quotes were meant to automatically escape values taken from request values, so you would not need to escape them when their are used in database queries in order to avoid SQL injection.

The problem with this is that in some PHP environments, this option is enabled, but in others it isn't.  So in practice you always have to have code to escape query values if you write code that will work regardless whether you have magic quotes enabled or not. This renders this option useless.

Magic quotes were deprecated in PHP 5.3. Killing this option in PHP 5.4 will not help anybody that wants to have code that works with past PHP versions in environments on which this option could have been enabled.

5. Binary notation for ints (0b10101) (+1)

PHP has support to define literal values for numbers represented in decimal, hexadecimal and octal notations. Support for binary literal values in PHP 5.4 seems useful but will result in a backwards incompatible error if you need to run code that uses this new notation in past PHP 5.3 versions.

In that case, you can use this notation only if you are sure you will be running in PHP 5.4 or later.

6. Array shortcuts. (+1)

The popularity of JSON inspired the idea that PHP could also have its equivalent notation for representing eventually complex structures using just PHP literal values. That is true except for objects which do not have a way to be represented literally.

Still for array literals, in PHP they are not represented in a way as compact as in JavaScript. Therefore this proposal is to support a shorter notation for array literals just like in JavaScript. This way a value like array('blah', 'blah') could be represented also as [ 'blah', 'blah' ].

It would not be backwards compatible but for code meant to run only in PHP 5.4 or later, it could be interesting.

While PHP core developers are at it, they could as well introduce object literal values like in JavaScript, so we could have a full JSON equivalent in PHP: PHPON - PHP Object Notation.

7. Option to disable POST data processing (+1)

PHP supports handling POST requests that send arbitrary data in the request body as additional parameters. That is the case for instance when handling SOAP protocol requests.

PHP scripts need to access the HTTP_RAW_POST_DATA variable or read the data from php://stdin virtual file. If you read the data from this virtual file, it is not necessary to set the HTTP_RAW_POST_DATA variable.

Despite there is an option name always_populate_raw_post_data to avoid populating this variable, there is some additional processing that in this case is not necessary. The idea of this feature is to have an additional option to completely disable the POST request data processing.

8. Built-in mini-HTTP server (+1)

I already discussed the proposal to have a built-in HTTP server with PHP in the Lately in PHP podcast. Having an HTTP server built-in PHP is always useful, so you do not rely on a separate program to develop and test your applications. It can also be used to develop small tools which provide a Web interface to configure them.

9. Session Handlers class (+1)

PHP default session handler can be replaced using separate classes that implement all session manipulation functions. Sometimes you just need to customize a part of the PHP default session handler behavior. In this case it would be useful if you could just replace a few functions.

10. Callback type check in arguments (+1)

Type hinting allows the verification of the array and object parameters being passed to function declared by name. Currently this does not work for callback functions assigned to variables. The idea of this feature to fill that gap.

Other features that may be voted and the PHP fork

As I mentioned, other features may still be included for voting if there is enough interest and commitment by the proponents to implement them.

Recently I wrote an article about a new PHP version fork by Robert Eisele. In reality he did not meant to maintain a forked PHP version.

He was approached by some PHP core developers which invited him to propose his fork new features, one by one, in the PHP internals mailing list. He already started doing that. So at least some of his PHP fork new features may still be voted for inclusion in PHP 5.4. 

The new voting process

Once the list of features to be voted, it is time to move on to the voting process.

Usually only PHP developers that PHP src karma are allowed to vote. This means those that have permissions to commit patches to change the main PHP source code.

Meanwhile a group of core developers recently decided to formalize a new proposal for the PHP voting process. Among other things, this proposal allows to extend the list of people that can vote to developers that do not have PHP src karma, but are leaders of well known and reputed PHP projects like CMS (Wordpress, Joomla, Drupal) or frameworks (CakePHP, Symphony, Zend Framework, etc..).

This sounds fair except for the detail of what constitutes a well known and reputed PHP project. Good common sense must prevail. Some PHP projects are evidently well known and reputed. But what about others which are not necessarily consensual reputed and well known PHP projects? I am afraid a new voting process is necessary to decide on case by case basis.

Anyway the new voting process is still a proposal. There will be a voting process to vote on that proposal. That process will end on next June 27.

PHP 5.4 Alpha 1 release date

There is no time to waste. The PHP 5.4 train is finally moving at a good pace. Once the new voting process proposal voting ends, the first PHP 5.4 alpha release will be announced. This means it will be relased on June 28.

I just could not determine if the new voting process proposal is approved, will the votes of developers without PHP src karma will already be accounted for the current set of features being proposed.

Conclusions

It seems to me that several traditional complaints against the way PHP development is carried by PHP core developers in the internals list are being addressed to make the process more clear and agile.

I mean, usually when you want to propose a feature, you go to the PHP internals list, present the feature, write an RFC and sometimes even offer a ready to be applied patch, but more than often you see an amazing effort of many developers trying to boycott your feature without giving you any hint on what to do to make the feature or your patch more acceptable.

This kind of behavior will not help PHP go anywhere. PHP does not need this level of cynicism. I suspect that this will still continue to happen but hopefully less frequently.

That is just my personal opinion. And you? What do you think about these happenings? Do you think things are going to improve and PHP community frustration will be reduced? Feel free to post a comment telling what you thing about it.