The namespacing dilemma

The advantages of namespacing

While not trying to explain what namespacing in PHP is I will go straight to an example of what makes it very attractive to me in a WordPress development ecosystem.
Say I’m developing a plugin called The average plugin and will prefix all of its functions and classes using the TADPlugin_ string like this

// file 'interface-Singleton.php' interface TADPlugin_Singleton { public static function get_instance(); public static function unset_instance(); } // file 'interface-Main.php' interface TADPlugin_Main { public function init(); public function run(); } // file 'MainClass.php' class TADPlugin_MainClass implements TADPlugin_Singleton, TADPlugin_Main { // properties //methods public static function get_instance(){ // implementation } public static function unset_instance(){ // implementation } public function init(){ // implementation } public function run(){ // implementation } } 

All this prefixing, in interfaces and class names in the example, can be avoided using namespacing to make code way more readable

// file 'interface-Singleton.php' namespace TADPlugin\Interfaces; interface Singleton { public static function get_instance(); public static function unset_instance(); } // file 'interface-Main.php' namespace TADPlugin\Interfaces; interface Main { public function init(); public function run(); } // file 'MainClass.php' namespace TADPlugin\Classes; use TADPlugin\Interfaces\Singleton; use TADPlugin\Interfaces\Main; class MainClass implements Singleton, Main { // properties //methods public static function get_instance(){ // implementation } public static function unset_instance(){ // implementation } public function init(){ // implementation } public function run(){ // implementation } } 

The PHP version dilemma

Namespacing was introduced in PHP version 5.3 and while you can find PHP version 5.4 and 5.5 running on some hosting services the problem arises when dealing with WordPress.
WordPress requirements for its most recent versions are:

* PHP version 5.2.4 for WordPress version 3.2 and above * PHP version 4.5 for WordPress version 3.1 

This means that the fact that a server can run the latest WordPress version it’s not a guarantee that the server will have PHP 5.3 installed.
And this is a problem if I plan to release WordPress plugins to the public or use them in lower-grade (read cheaper) hosting services.

Adoptions stats anyone?

I really like namespacing and would like to know the potential loss of not supporting PHP versions lesser than 5.3 in my plugins.
A quick Google search turns out this page and this tells me that:

* 81.4% of all the websites use PHP * 41.3% of all the websites use PHP version 5.3.* 

So half the websites that use PHP use the version supporting namespacing. In my idea of a fast-moving IT world I thought the adoption rate to be much more massive: PHP version 5.3 was released in 2009 and support for version 5.2 ended in December 2010. Three years ago.

I’ll take the bet but know the drill

Since all the self-hosting services me and the clients got until now do run PHP version at least 5.3 I’m going for it but I think that the look at the stats and the thought about it was not a waste of time. Supporting broken plugins due to missing language version features would not be fun.

One thought on “The namespacing dilemma

  1. I don’t think it’s really worth your time to sacrifice quality code for old PHP versions. Sure you may lose a handful of users who don’t know how to upgrade their hosting or refuse to, but at the same time, they’ll live. We also need to stop catering to the old versions of php anyway, especially ones that have long been out of even security releases.

I appreciate your input