PHP 5.3 - A Heavy Hitter in Training

Mar12
Missing Image
By SiteCrafting Staff

The evolution of PHP into an object-oriented programming language has been a very exciting process to watch. I'll admit its advancement seems to move at a glacial pace at times, but looking back we certainly have come a long way. With the release of 5.0 we saw PHP leave its childhood and enter its awkward adolescent stage. At this point there is evidence of a mature and complex object-oriented language while stilll exhibiting many of its younger habits.

So what's in store for us next? Find out after the jump . . .



This release may be the most significant update PHP has seen since PHP 5. This is because many of the features planned for the first release of PHP 6 are being backported to 5.3. Anyone that has been folowing the development of PHP is likely aware that 6.0 will represent its entrance into what I like to call its adulthood. This milestone will mark the end of support for deprecated non compliant code, and will fully embrace an OO coding style. It's not going to be the end-all be-all version of PHP, but it will no longer attempt to cling to its procedural roots.

Let's take a look at some of the goodies in store for us in PHP 5.3:

I. Native MySQL Support

As of right now PHP has made use of the external library libmysql to access MySQL databases, which is fine - it works and it works well, so no complaints here. However, the relationship that has developed between PHP and MySQL is quite widespread, and I must admit it seems odd that MySQL has never truly been natively supported. All that will change in 5.3, when PHP will natively support MySQL resulting in a significant performance boost.

II. Variable Static Calls

You are probably already familiar with variable variables and variable function calls. Variable static calls are the next logical addition to this feature set. This concept is best illustrated with an example, so consider the following:

$className 'StringUtils';
$functionName 'FormatPhoneNumber';

$phoneNumber '2535552552';
$newPhoneNumber $className::$functionName($phoneNumber);

echo 
$newPhoneNumber;

If we assume that the function StringUtils::FormatPhoneNumber() formats the phone number into a friendly layout, we could expect the above script to output "(253) 555-2552" or something similar. This adds a tremendous degree of flexibility to your code, as I'm sure you can already imagine.

III. Error Reporting

Error reporting has been expanded and has split E_STRICT into two separate reporting levels. E_STRICT now only reports on bad coding style and leaves deprecated code (code that will not be supported much longer) to the E_DEPRECATED level.

Additionally, E_ALL will actually include E_STRICT errors as well (which is what most of us expected to happen when it was first introduced).

IIV. Namespaces

I saved the best for last. Namespace support is hands-down the feature I am most excited about. This is some thing many developers with experience in other languages have been clamoring for since PHP first started supporting classes. Namespaces allow you to group related classes together and help to avoid naming conflicts in more complex applications.

Currently the only way to accomplish this is to simulate namespace funcionality by using very long class names. Consider the Zend Framework as an example, in which you end up with class names like "Zend_Auth_Adapter_Http_Resolver_File" or "Zend_Controller_Router_Route_Module" - just mildly inconvenient, isn't it?

As of PHP 5.3 one could place these classes in namespaces, making them much more manageable:

namespace Zend::Auth::Adapter::Http::Resolver

class File {
    public function 
__construct() {
        
// Do something here...
    
}

    public function 
setFile($path) {
        
// Do something else here...
    
}
}

We could then instantiate the class like this:

use Zend::Auth::Adapter::Http::Resolver as HttpResolver;
 
$file = new HttpResolver::File();
$file->setFile('/home/testuser/file.tmp');

In the above case, we can now instantiate all classes within this namespace using a similar declaration. As you can see, the addition of namespaces allows you to declare the namespace in which a script will execute, greatly shortening the required class declaration. This also introduces the possiblity of namespace aliases, allowing you to reference a namespace with a shorter 'nickname.'

We could have called the class directly from the namespace (like "new Zend::Auth::Adapter::Http::Resolver::File()") and left out the use construct, but then we would be back to a long class declaration. Even then, this time around PHP will actually be aware of the namespace (and potentially future IDEs, leading to more powerful code-hinting).

Conclusion

That was just a sample of what you can expect when 5.3 is released. With so many additions that were originally planned for PHP 6, this release is going to feel like an early birthday present. This also means we can see these features added to our production environments more quickly considering an upgrade to 5.3 will go much more quickly than a migration to an entirely new verison.


Dev

Back To Feed