PHP 5 Features

What are new features introduced in PHP 5

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.
   2. 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.
   3. 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.
   4. It seems to me that the way it is, type hinting in PHP is an half done feature because common data types are excluded.
   5. 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.
   6. 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.
   2. 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.
   3. 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.
   4. 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.
   5. 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.
   6. 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.
   7. 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.
   8. 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.
   9. 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.
   10. 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.
   2. 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.
   3. 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.
   2. 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.
   2. 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' ].
   3. It would not be backwards compatible but for code meant to run only in PHP 5.4 or later, it could be interesting.
   4. 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.
   2. 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.
   3. 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.
   2. 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.
    2. Other features that may be voted and the PHP fork