Namespacing Perch

As we work towards Perch 2.5, one of the technical aspects of the product that we’re looking at is PHP namespacing. In this reasonably technical post, I’ll be examining what that means for Perch and asking some questions of those who see this as a desirable move.

Since its launch nearly five years ago, Perch has had a minimum requirement of PHP 5.2. That has meant that the architecture of the application is designed to work with PHP 5.2’s view of the world. That world did not include namespaces, as they weren’t available until PHP 5.3 was released. With Perch 2.5 we’re raising that minimum requirement to PHP 5.3 which now makes the use of namespaces possible.

So what are namespaces? Namespaces solve a problem that arrises with conflicting names when you combine code from two or more sources. If my code defines a function called connect_to_database() and your code also defines a function called connect_to_database() then our code can’t ever be used together, and PHP requires every function within scope to be named uniquely. (It’s not just functions, but classes, constants, interfaces, all the major language building blocks.)

This is why everything in Perch is named PerchSomething or perch_something() or PERCH_SOMETHING – to decrease the likelihood of a name collision.

Namespaces solve this problem by giving us each our own named space to work in. I can call my function Perch\connect_to_database() and you can call yours MmmPizza\connect_to_database() and no name conflict exists. (We’ll gloss over the fact that namespaces just push the problem one level higher, and collisions of namespaces can still occur.)

This is relevant to Perch, because Perch is often used as a content management component within a bigger system or app. That means that Perch code runs alongside other custom code and things like MVC frameworks, most of which are already using namespaces.

Namespaces seem like a good way to go from a practical perspective, and from the point of view of having good, well structured code (which in turn helps us keep Perch easy to maintain and keep the bug count low). But it’s never that simple, is it?

One deliberate design decision with Perch is that it dumps things into the global (i.e. common-to-all-code) namespace. When you call up some content to your page using perch_content(), that only works because the perch_content() function has been deliberately created right in PHP’s theatre of war, the global namespace. It’s designed that way to make it as easy as possible for people who aren’t PHP developers to be able to get up and running. You don’t need to instantiate objects of a given class, or call static methods, and you certainly don’t need to know how to declare a namespace.

If we were to namespace everything, things like calling perch_content() from the page would no longer work. There’d need to be some sort of change to every page in every website using Perch, and that’s not something we’re going to do any time soon. So we’re squarely into compromise zone. And that’s where I need you.

I’ve got some ideas of the various ways a good compromise can be achieved, but in order to come up with the best solution, I need to really understand the practical problems you face using the current non-namespaced Perch within other applications and frameworks. I get the namespacing is better, I understand the theory, but I’m going to need to be creative here, so I need the nuts and bolts of what the practical issues you face are using Perch without a namespace.

For example, are all those functions like perch_content() that get dumped into the global namespace a problem? What do you really need to be able to do that you can’t achieve or have to work around? What’s your workaround?

If you’ve come across problems with Perch not being namespaced, I really need to your input to make sure that the fix is going to work for you. Either leave a comment here, or you can email hello@grabaperch.com if you prefer. I’d really appreciate your feedback.