Why Object-Oriented Programming is Bad for Drupal
I have led or contributed to dozens of Open Source projects. And with one exception, all of my code has been Object Oriented. (That one exception is Drupal.) Java, Python, PHP, and even OO Perl... I'm a dyed-in-the-wool OO developer. So this may come as a shock to anyone who knows me, but I am about to make the argument that OO is bad for Drupal.
Trust me, this is not a high point in my development life. I feel like I'm telling my child that she should skip college; that such a level of sophistication is just not necessary in her life. And I guess in a way that is precisely what I am saying. <!--break-->
1. Complexity is the antithesis of the Drupal way
Why does Drupal have thousands of modules while other CMSes -- many older than Drupal -- have far less? The reason is as clear as day. Drupal modules are simple to develop. And this is not just because hooks are easy to use, but because the API has long been focused on making hard things easy.
But we're part way into a reversal: Easy things are getting harder and harder.
It struck me during a conversation with a friend of mine. He is an excellent PHP developer who has worked with Drupal longer than I have. He lamented how Drupal 4.7 was so much better than Drupal 6. When I asked why, he began to enumerate the ways in which Drupal has gotten more complex over the years. This is not some kid out of college wishing life was as good as the dorm days. He's a seasoned developer, and his insights were penetrating.
At one time, it was possible for an average developer to know Drupal. Now, few people (perhaps 5-10) understand all of Drupal's core systems. One point really caught me. It's not just the code base that is complex. It's the plethora of subsystems, of methods of passing data, of specialized conventions, even of terminology. Drupal is a conceptual behemoth.
Introducing OO into this picture is not a simplification. In fact, it is a massive infusion of complexity. Many Drupal developers are now having to learn a new set of programming practices. The conceptual depth of Drupal 7 is abyssal. Nodes, fields, entities, users, comments, menus, the other menus, views, the other views, queries, filters, actions, hooks, theme functions, preprocessors, templates, modules... To Drupal 8, we're adding again! Contexts, plugins.... These new OO subsystems will have (or already have) new conventions and new terminology and new programming practices. How will a newcomer ever understand this?
Is "keeping it in perspective" the answer? What are we going to get out of this new trend? A "better" system at what cost? Contributors and users. They will defect. Drupal is becoming the dream of the lazy consultant: Tons of jargon, plenty of complexity, and a call stack that requires a wall-sized chalk board to diagram.
2. Private, protected, and philosophically discordant
The debate over whether or not private and protected keywords should be used in Drupal has been an eye-opener for me. Not because I think people are being petty. In fact, it's the opposite. People are being deep.
For us OO-minded people, we can't fathom why anyone would call into question the utility of protected variables. Heresy! And we have our small arsenal of arguments in favor of private properties even in FOSS projects. But when it comes down to it, the entire purpose of private and protected members is to keep other things (read: annoying programmers with "great ideas") from modifying our precious data.
Drupal's just not into that.
In fact, the (welcomed) death knell of the static anti-pattern came in the form of drupal_static(), which now provides uncontrolled access to the only mechanism we once had for controlling globally-scoped data. Function statics are now as public as global variables!
What does this illustrate? Drupal has long been all about letting developers shoot themselves (or their websites) in the foot by doing stupid things. Drupal has never been about saving the developer from herself, or protecting my API from the insidious intentions of other developers. So what we have here is a deep philosophical difference between Object Oriented architectures and Drupal's laissez-faire disposition. Why try to blend contraries?
3. A shapeless and mish-mashy agglomeration of technique
Why does Drupal have a distinction between themers and developers? One huge reason is because the two layers have distinct architectures and conventions. PHP templates are written like circa 1997 PHP3 (as Rasmus intended!). They if; they else; they print. EOF. Modules, on the other hand, are are so data driven that if a bit of markup sneaks into your module (and it's not in a theme function), you can expect repercussions in your issue queue.
So there are two different techniques that the Rock Star (gasp... did I just say that?) Drupal developer has to master. Right? Well... actually, there are more.
There are hooks, an almost-novelty in the PHP programming sphere. And nested arrays -- the One Datastructure to Rule Them All in some people's view. The closest thing I've ever seen to FAPI arrays outside of Drupal is the LDAP API... and that's like comparing the Yankees to a little league team. There are .info files, which are almost just like PHP .ini files. There are programmatically important naming conventions for functions, file extensions, directories, database tables, SQL statements, rendering arrays, and strings. All are different, of course. Where one might expect five functions, there is only one... with an $op argument. These are not standard programming practices outside of Drupal. We already expect a lot out of our developers.
Drupal already has a nuanced procedural/functional blend of styles (with some Aspect Oriented theory to spice it up). And it has a host of deeply entrenched, though novel, conventions built on those techniques. And now we're talking about adding in another major new coding technique? How many books have you seen on OO theory and practice? And how is that going to mesh with our existing architecture?
But seriously... why is this a problem? There are two reasons:
- Consistency: How can one build anything approximating a consistent architecture when there are always at least three competing theories as to how it ought to be done?
- Reusability: I'm not talking code. I'm talking wetware. As our coding style diverges farther and farther from mainstream, it becomes harder for neophytes to figure out how to do things. Drupalish OOP is just introducing yet another anomaly for the new user to figure out.
4. Refactoring: The great Shark-Jumping faux pas of FOSS projects
How do you kill an Open Source project? You rewrite the whole thing. And the great FOSS example par excellence for that is... PERL!
Now that we've started down the OO trail, everything is looking like a candidate for refactoring. How loudly are people complaining about the timeline for Drupal 7? And how long and loud will people complain before they get distracted by something shiny... and simpler... and perceived to be "more active"? How many people are going to tolerate a huge API change when they could more easily just learn something else?
This is one significant reason, I think, to actively resist jumping over the waterfall of OO API rewrites.
5. Controversy sucks time
For a long time I never understood why people read the magazines sold at the cash registers in grocery stores. Who cares if Britney leaves her kid in the back seat while she buys pet food? Why would it matter that two rich Hollywood celebs are calling off their three-month marriage?
But the answer hit me about the twelfth time I refreshed Twitter during DrupalCon Copenhagen: humans (including me) love controversy. So much so that we are easily distracted by it -- away from things we ostensibly care about a lot more.
Once we start blending major programming styles like we are starting to do, we open up a great can of worms. Now it's gonna be the Gang of Four (Object Oriented guys who are by all accounts far less evil than Mao's group) vs. Kernigan and Ritchie. And time and time again we will see clashes that will generate fresh controversy. The time-wasting potential is already manifesting itself (in this very post?).
Should we blackball OOP?
What is the bottom line? Should we ban-by-fiat all OO? I don't think so. In some cases, I think it is probably an appropriate choice. I, for one, think the chaining features of the new database API are a great way to actually fulfill Drupal's goals. Yet I find myself startlingly reticent to recommend anywhere else where I think OO should come to the fore.
Sure, here and there we see contrib modules make great use of OO, and we should treat contrib modules as we always have: as the sovereign domain of their contributors.
But for core, it's time to throttle the OO efforts and take a good, hard look at how we keep Drupal's APIs... well... Drupalish.
