Can I use namespaces in my plugin?

Question

I am building a plugin that I hope to eventually put on Envato CodeCanyon.

Currently I am creating functions of the form mypluginname_action. This is quickly becoming silly as I have to do that a lot. I'm thinking of using PHP namespaces, but I'm worried that there might be a reason why I shouldn't.

1. Are namespaces compatible with WordPress and Envato's coding standards?
2. Can I use namespaces in the PHP versions that I should be supporting?
3. Are there any professional theme/plugin makers who make use of the namespace feature? If not, why not? Are there any common pitfalls with using namespaces?

I am well aware that I can research all of this myself, and of course I will, but as I'm early in development, at this point I'm hoping for a quick answer from more experienced people who might have already looked into this.

I appreciate any thoughts on this.

Answer 1

It's almost four years after I asked this question. For anyone reading this now, namespaces are officially supported. From the 5.2 release notes:

The minimum supported PHP version is now 5.6.20. As of WordPress 5.2, themes and plugins can safely take advantage of namespaces, anonymous functions, and more!

Answer 2

You can totally use namespaces in your project/theme/plugin!

The only drawback is that you introduce a PHP 5.3 dependency, while WordPress itself only requires 5.2.4.

I guess in 2015 this is not a big issue, even when distributing a plugin to a wide community (opensource or envato).

Roots team is using namespaces in their themes, plugins, etc: https://github.com/roots/sage

Answer 3

In a way you are over complicating things for yourself, but OTOH you are being too simplistic.

You should not sell software that you can not test. If you claim that your software works on all versions of wordpress starting with 3.5 and php starting with 5.3 you might be ok if you do not test all the combinations, but if some version will prove not to work with your code then you will have to spend unexpected time to fix it. The extra time might be the difference between a profit and lose, and while you are working to fix it, your reputation might be irrecoverably tarnished.

Right now wordpress recommends 5.6 so start with it, write good unit tests and once your code works on 5.6 you can try to run it on 5.5 etc and see where it breaks. I would say that at this stage don't bother to fix the error, and wait until there is a demand to compatibility with that version, and how big it is, to decide if you actually want to put the effort into supporting it.