Last week I was listening to Dries' opening keynote at DrupalCon Chicago. He was speaking about the next version, when a phrase I would not have associated with Drupal made my ears perk up. That phrase was "Dependency Injection". That's a pretty familiar concept to me, having worked with Java for the past decade or so. I've since read some things where he states there are things we should learn from Java. (Before anyone runs off screaming, "learn from" does not equal "copy".) Steps were taken toward object orientation in Drupal 6, and more followed in 7. Presumably in 8 OO will become pervasive.

So what is dependency injection? Some call it the "Hollywood Principle"... "Don't call me, I'll call you." The idea is that an object shouldn't be calling an external resource, like a file or a database, because that could change. The object just has a reference to what it needs, and the actual resource is injected by the framework it lives in - in this case, Drupal.

Thus, if a file that a class depends on is moved, or a different type is database is used, you just change a configuration file instead of your code. An additional benefit is now that testing becomes easier - you just run the code against different config files. The injected resources can even be "mocks" for things you don't have easy access to, or other classes that haven't been written yet.

Another OO concept coming into version 8 is context. This is basically so an object can know about the environment it's running in. PHP and Drupal currently use global variables for this, but they're neither swappable (for testing) nor extensible.

There's a project called Butler that attempts to bring this functionality, and more. It's contrib in Drupal 7 and aspires to be core in 8.

These steps are bound to result in more debate in "Drupal as a Framework" vs. "Drupal as a Platform". Dries has already said the answer is "both" but it will be an interesting balancing act. OO in PHP is relatively new, and I suspect many of the current maodule writers/maintainers will not be too happy at having to learn it... it requires a different way of thinking. For those willing to make the jump, it will be rewarding, but I'm sure a lot of people will simply move onto something else.

Despite that, I definitely think that a more object-oriented Drupal is a good move for stability an security. But it's going to be challenging transition. I believe modules will become more "tools" and less oriented toward specific output generation. In other words, modules will be more about letting less technical people generate output in various ways. I liken it to auto mechanics... in cars' early days, you had to know how to fix a car to drive one. Later we got to the point of "shadetree mechanics", where you could fix one with basic knowledge if you really wanted to. But now, cars are so complex that for anything beyond the basics, you have to go to an expert.

So the challenge for the community is to give most website builders what they need to do without having to do a "deep-dive". Drupal Gardens is a step in this direction. And the task-specific Drupal distros, like COD and Open Atrium, will fill in some technical gaps.

I for one welcome our new OO overlords. Hey, maybe one day, we'll even figure out API deprecation so we don't have to rewrite everything for a new release