In the last post, I said we couldn’t afford some of the same luxuries that statically typed, compiled languages have. Specifically, I was talking about the idea of not having to deal with autoloaders.

Instead, compiled languages can take all of the files that make up the program, process them, and bundle them up into a single binary.

But to do that, it needs a specific type of a program to do that.

Autoloading in WordPress: Linkers and Autoloaders

That is, it uses a utility called a linker. I’ll cover that briefly momentarily, but seeing the role it plays in the context of compiled languages can help draw an analogy with how autoloading in WordPress (and PHP) works.

What’s a Linker?

Depending on the language with which you’re working, especially with object-oriented programming languages, it’s likely that code is going to be spread across multiple files.

Further, each of these files is going to be bundled into their packages (we refer to these as namespaces as PHP, and most compiled languages do the same, too). So, for demonstration purposes, assume that the files are included in their namespaces.

Then, throughout the codebase, you’ve got all of these files that are related via namespaces but spread across separate files.

Autoloading in WordPress: Linkers

When it comes time to compile all of this into a single, executable binary, a program called a linker analyzes the code and works it magic to help create a single, executable binary (versus a collection of files like we’re used to seeing in PHP-based projects).

And Autoloading?

So what are the similarities between autoloading and linking? As mentioned, the projects that we build in WordPress (and PHP) consistently reside in separate files. That is, they’ll never be compiled into one file.

I would say once upon a time (although this still happens), we use include_once or require_once to bring in all the dependencies that we need. But autoloading negates the need to do this.

Autoloading in WordPress: Without Using PSR4

Manually writing an autoloader (without using PSR4).

Instead, an autoloader can take the code that we have whenever we, say, instantiate a class and then automatically load (hence its name) the file without the need to manually include the file.

The Analogy

Whereas a linker will analyze the codebase of a program and automatically assemble the binary, an autoloader will need some type of configuration to let it know where the classes are, how to locate a file on the file system given its namespace and class name, and so on.

Further, there are different ways this can be done depending on if you opt to use something like PSR-4 or another loading strategy. But that’s beyond the scope of this post.

That’s It

The idea behind all of this is to understand how statically typed languages, which are often – though not always – compiled languages and how dynamically typed – which are often not compiled (think JavaScript, PHP, etc.) – can work in similar, albeit different ways.

In short:

  • compiled languages use linkers,
  • dynamic languages use autoloaders.

And that’s all there is to it, really.

But why is this important? To understand the benefits of autoloading in WordPress and to have a foundation for more advanced topics, I find that it’s important to understand the how and why we do certain things we do.

And if nothing else, it can help us be better developers.