In my talk for this year’s WordCamp Atlanta, I’m going to be talking about namespaces and autoloading in WordPress.
While working on my presentation:
- I’ve been working on a project for someone in which I’m writing an autoloader from scratch,
- I’m talking with other developers about their preferences with writing autoloaders,
- I’m looking at open-source projects to see how others are writing autoloaders.
All of this is primarily done to see how, if it isn’t obvious, others implement namespaces and autoloading in their projects. What’s interesting is that there seem to be three main ways in which people go about doing it.
Namespaces and Autoloading
Before going into the way I currently approach writing an autoloader, I thought I’d share the three ways I’ve found others implementing their autoloaders.
What I’ve Found
And note that this is primarily meant just to be interesting, not to offer any commentary on what way is correct or which way is not.
- Writing an autoloader using procedural code even if the rest of the code base is object-oriented,
- Writing an autoloader using object-oriented code regardless of which paradigm is used for the rest of the codebase,
- Using a dependency manager, like Composer, to load all of the dependencies and forgoing PHP’s facilities for autoloading altogether.
For what it’s worth, I think there’s something to using Composer as an autoloader, but it requires a little more experience with additional tooling than just PHP and the manual to use it. That is to say; it may not be for everyone.
What I Do
I know I’ve written about this before, but I’ve also spent time on different projects writing autoloaders in two different ways:
- using procedural code,
- using object-oriented code.
And as much of a fan as I am of object-oriented programming, I prefer to write my autoloaders using procedural code.
But there’s a caveat to this. It assumes the following:
- my code is organized in directories that map to their namespaces,
- I have a standard by which I’m naming my files (regardless of if it’s PSR or WPCS).
With those two pieces in place, I can usually reuse the same autoloader in multiple projects. This is because it’s predicated on the predictability of the organization and standard of the code and because the code is easy to comment (and thus should be easy to follow) thus easy to maintain.
Only as Much as Needed
There’s one other aspect to writing autoloaders that I’ve come across when working on projects for others in which I can’t always use the standards I prefer: I write only as much as I need.
For example, say that you’re going to write an autoloader for a WordPress plugin. The code has its type of directory structure and file-naming convention so you can’t just reuse something you’ve already written. Further, the project has classes but no interfaces or abstract classes.
And remember: You’re writing the autoloader from scratch.
When doing this, I think some of us have a propensity to want to write an autoloader that supports all of the above but also has support in case an interface or abstract class is ever introduced.
I used to be that way (and maybe I’m the only one that’s every been that way ).
But now I tend to write just enough to make sure it works. That means I will write an autoloader for the above requirements so that it satisfies the use case, but I won’t write code for something, like interfaces or abstract classes, that may never be used.
I can always come back and add that later.
Sharing All of This
For those who are interested, I’ve also been convinced by a friend to publish a post that walks through all of the content in my presentation.
I’m already planning to have a repository on GitHub with examples that I’ll be using during my talk as well as the slide deck that I’ll be using so this is one more thing that I’ll aim to publish when I give my talk.
And for those who are interested, I’m sharing a couple of shots on Instagram each day as I slowly work my way through putting together the presentation (and as I continue to look for different types of things to share on the social network ).