In the previous post, I covered a few points as to why I think that include_once, require_once, and other similar statements result in poor development practices (at least when it comes to the work we’re doing with our WordPress projects).
If you haven’t read it, no big deal. The gist of the post is that these statements make:
- debugging more difficult,
- tracing code harder to do.
Ultimately, they are things we can avoid. I ended the post with the following:
This still leaves the question of why autoloading (or any inclusion of third-party files) is needed at all.
And though I’d love to cover all the details in this post, it’s going to take this and one more post as its important to understand some foundational topics on languages, interpreters, and compilers before getting too far ahead.
Autoloading in WordPress: Types of Languages
When it comes to programming languages, they can be broken down into two distinct types of languages:
They are easy to spot, too.
A statically-typed language means that when you declare a variable, like a string, an integer, or a floating point number, it maintains that type throughout its entire lifetime.
This doesn’t mean it can’t be changed or parsed into another type, but the idea is you declare its type and that’s how it’s operated.
It’s generally specified as a certain type when it’s declared, like string or int, and it’s most often seen in compiled languages.
Dynamically-typed languages, on the other hand, have variables that are more fluid, for lack of a better term, in nature.
That is, you may initially declare it as a string then compare it to an integer and later use it as a string again.
The interpreter or compiler (depending on what language you’re using) will do the best it can to infer what you’re trying to do based on the context of what you’re doing in your code but it’s not always right.
That can lead to weird side effects and bugs.
Notice that when we use a standard double-equals sign, the interpreter coerces the string into the boolean type even though the true string is not true.
The second case is accurate (and it’s why triple-equals should almost always be used).
Furthermore, how something may work in one language is not how it may work in another language.
The bottom line is that don’t expect your languages to do the same thing just because they may support dynamic typing.
What’s This Have to Do With Autoloading?
Okay, so we’ve done a bit of talking about primitives and all of that is fine but it doesn’t do a whole lot when talking about classes, objects, instantiation, autoloading, and so on does it?
The purpose of bringing up the aforementioned topics is to show the role that interpreters and compilers play when working with code in dynamic languages.
And this is important because PHP is a dynamic language.
At this point, I was originally going to begin looking at sample PHP code, namespaces, autoloading, include statements, and all of that, but I try to keep my articles at a certain length and this began to stretch a little further than I wanted.
So the ultimate take away from this post, if I had to summarize it, is this:
Dynamically typed languages, like PHP, are not given the luxury of compiled languages where everything is compiled into a single binary. We have to tell the program, in some way, where the dependencies exist within the context of the larger program.
And that’s what I’ll aim to cover in the next post.