PHP Classes

Top 10 PHP 5.4 features to vote

Recommend this page to a friend!
  Blog PHP Classes blog   RSS 1.0 feed RSS 2.0 feed   Blog Top 10 PHP 5.4 featur...   Post a comment Post a comment   See comments See comments (9)   Trackbacks (1)  


Viewers: 14

Last month viewers: 4

Categories: PHP community, News

The process to release PHP 5.4 is moving on. Now it is the time to vote the features that should be included or not.

Read this article to learn which are the features being voted for inclusion in PHP 5.4 and when the first release is expected to happen.

Loaded Article


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


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.

2. Make primitive type names reserved words (-1)

Type hinting is a feature that is meant to overcome the lack of strict typing in PHP. That helps developers to detect bugs earlier in their development process by checking the type of the parameters passed to function against expected types specified in the function declaration. These expected function parameter types are called type hints.

PHP already had type hints for functions expecting object parameter types. However, the support for any form of type checking for scalar types (say integers, floating point numbers, boolean and strings) was something that was never consensual.

I could never understand what exactly were the objections of those that wanted object type hinting, but opposed to have scalar type hinting. Maybe I missed the messages where somebody opposed to scalar type hinting explained their objections.

It seems to me that the way it is, type hinting in PHP is an half done feature because common data types are excluded.

Anyway, while the debate goes one, this feature proposal is meant to turn the names of scalar data types as reserved words, just in case scalar data type hinting is finally accepted.

Well, I am in favor of a full data type hinting, but forbidding the use of variables or even just function parameters like $string or $integer seems to be a bad idea. The problem is that such restriction did not exist it the past. So, if approved, this feature will make some old code stop working.

3. Add E_STRICT to E_ALL (-1)

PHP configuration has several warning flags that let you control which runtime errors should be reported as notices. Notices are useful to let developers detect problems caused by eventual bugs in their code.

E_ALL is an error reporting value that aggregates several error reporting levels. Currently that excludes E_STRICT. That is an error level that is triggered when more pedantic errors occur.

Usually E_STRICT triggered errors do not affect code that already runs well. That is why many PHP production environments are configured to only have E_ALL set, thus not having E_STRICT notices enabled.

E_STRICT is more used in development environments to help catching at least some more pedantic errors, ignoring others which developers are aware and result from situations which are not really bugs.

Therefore I am afraid that adding E_STRICT to E_ALL will only annoy developers that do not care about E_STRICT notices because such notices are not useful to them when triggered in the production environment.

If this feature is approved, those developers will have to tweak their sites PHP configuration to replace E_ALL by all the individual error levels, except for E_STRICT.

However, I am afraid that this feature may cause a side effect that I saw happening a lot during the early PHP 5 days. If developers see too many new errors they did not have before, they may simply refuse to upgrade to PHP 5.4. It would be a too big hassle to avoid the warnings. This may delay PHP 5.4 adoption for many years, just like it happened to PHP 5.

Despite it is just a matter of tweaking PHP error reporting setting as I described above, in many cases developers do not have a way to change the PHP configuration, which is particularly true in shared hosting environments.

Personally I would rather see a feature that would allow disabling certain error types individually. I saw that feature a long time ago in SAS C/C++ compiler when I used to develop for the Amiga computers.

Each error would have an assigned number. If you wanted to just suppress an error of a specific type, you could add the respective error code to the error suppression list. It would be helpful to help us focusing on notices that are really caused by bugs, and not be distracted by useless pedantic errors.

But this would be a whole new feature in itself.

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.

The idea of this feature is to be able to customize the default PHP session handler behavior just by extending a new class that is going to encapsulate all the PHP session handler functionality.

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.


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.

You need to be a registered user or login to post a comment

1,615,696 PHP developers registered to the PHP Classes site.
Be One of Us!

Login Immediately with your account on:


5. Multibyte support? - Carlos Aguado (2011-07-05 10:42)
Will multibyte support be included in PHP 5.4?... - 1 reply
Read the whole comment and replies

3. Suggestion for PHP5.4 - ankur gupta (2011-06-28 18:38)
My suggestion for PHP 5.4 is:... - 2 replies
Read the whole comment and replies

4. ouch - m3ta (2011-06-24 19:03)
Illiteracy... - 1 reply
Read the whole comment and replies

2. No big deal for me - Scott Baker (2011-06-23 15:56)
None of these changes will even impact my development... - 0 replies
Read the whole comment and replies

1. Type Hinting - Fernando André (2011-06-22 17:35)
Type hinting +1... - 0 replies
Read the whole comment and replies


1. New in PHP 5.4 (French) (2011-07-25 08:55)
Here is a partial list of new PHP 5.4 features...

  Blog PHP Classes blog   RSS 1.0 feed RSS 2.0 feed   Blog Top 10 PHP 5.4 featur...   Post a comment Post a comment   See comments See comments (9)   Trackbacks (1)