///Say hello to namespace naming conventions!

Say hello to namespace naming conventions!

First, we had variable naming conventions. Then we got classes and functions / methods, so we got general naming conventions. With PHP 5.3 introducing namespaces, it’s time to say hello to namespace naming conventions.

Namespaces were introduced to solve the problem of naming clashes. Once upon a time, all your code lived in one, two, maybe three files, and you could see and know exactly what was going on. Then applications started expanding, and OOP came along. Suddenly there were hundreds of functions, classes and methods in your application, not to mention variables and properties.

It was generally accepted that names should therefore be descriptive. However, names soon became very brief and generic, such as new(), Blog::add_post(), $config etc. All very well when you controlled all the code in the scope of your application, but the moment you came to integrating or reusing code everything went awry. To avoid this, names were long winded, prefixed and determinedly different.

So, where do namespaces fit in? Well, first we had raw procedural code, then we had functions, then we put functions inside classes. The best way to explain namespaces is that we can now put functions inside classes inside namespaces. this page has some good samples.

Of course, this is only going to work if namespaces names are unique.

Once PHP 5.3 goes mainstream, I suspect we’ll see the same trends in namespace naming as we did in class / package naming. In the samples used to demonstrate namespaces, we’ve seen anything from Company::Project::Package containing classs Package, Package_Something, Package_Something_Else; to MyProject::Package::Class containing class Class.

Ideally, we’d have [OriginOfCode::]Project::Package[::SubPackage] for naming conventions. The origin of the code could be the project itself (e.g. for open source collaborative projects), and could be omitted where appropriate. Subpackages would have to be clearly defined – there is no need to create a seperate namespace just for a new class. On the other hand, it makes perfect sense to have Zend::Framework::Service::Delicious and Zend::Framework::Service::Akismet.

Taking this to the extreme, we maintain a global list of TLNs – like TLDs, but Top Level Namespaces – and have a basic registration system. $0.25 to register your very own JohnCitizen namespace in PHP history? Each developer/company/project could then manage their top level namespace – and, if they so desire, park it with keyword-rich classes commented with ads for the latest and greatest in commercial PHP development tools. Just kidding.

So, what are your thoughts on namespaces and naming conventions? Should we be enforcing certain formats for namespace names? Will we ever see Microsoft::Windows::Core::Filesystem::Utils::Defragement, or will namespaces be the final solution to ensuring code can co-exist as the one big happy family that is the PHP ecosystem?

2008-03-01T04:50:45+00:00 March 1st, 2008|PHP|0 Comments

About the Author:

Leave A Comment