Want to get Lullabot article, videocast, and podcast announcements delivered right to your in-box?
Let us know your email address (we won't share it) and we'll let you know when anything exciting happens.
Drupal's Continuous Tax, or: Should We OOP?
September 30, 2007
Blogger Crazy Bob recently commented on something he calls "The Continuous Tax" -- the time and energy that must be invested in building and maintaining APIs to do something your programming language doesn't handle for you automatically.
The discussion in question focused on the nature of ActiveRecord in Ruby On Rails and how it compares to strongly-typed ORM systems in Java. That won't mean much to most people in the Drupal community, but the underlying conflict mirrors a hot debate currently brewing in our neighborhood. Specifically, should Drupal use PHP's new OOP features?
Traditionally, Drupal has used plain vanilla procedural PHP to acomplish a wide variety of cool tricks. (It's a good lesson for those who say that design patterns can only be used with OOP languages; Drupal's hook system and theming system use naming conventions to implement visitor patterns, chains of responsibility, and so on. The entire FormAPI system is, as many have argued, a lightweight object oriented system implemented with arrays.) While many underlying concepts of object orientation are embraced, Drupal was also written when PHP's OOP features, well... kind of sucked.
That will change about a year from now, when Drupal 7 is slated for release. We're dropping support for versions of PHP earlier than 5.2, which means that a host of OOP improvements in the language will be at our disposal. Some obvious candidates for OOP refactoring are already in the pipeline: PHP 5's improved PDO database library is OOP by nature, so we'll be using it under the hood. There are, though, dozens of other parts of Drupal that might benefit from an OOP refactoring. Should we take advantage of that in Drupal 7? Why not make 2008 "The Year Drupal Goes OOP?"
The easy answer is, "It already works." One of geek guru Joel Spolsky's cardinal rules is, "Rewriting from scratch is a mistake." All the gains you think you'll make by tossing out your old crufty code and starting fresh are usually wiped out by the energy needed to recreate years of tricky debugging and carefully balanced edge cases. And make no mistake -- reimplementing Drupal with PHP's OOP language features would be a complete rewrite. Because so much of Drupal's code is dedicated to achieving OOP-like functionality in procedural code, it will require fundamental rethinking of core architectural issues like "hooks" and "nodeapi" and "how we store data."
So, does that mean we shouldn't use OOP? No. The flip side of the coin is Crazy Bob's comment about the "Continuous Tax." Drupal's use of PHP makes sense for a CMS that needs to be accessible to a wide audience. But the lack of language features in earlier versions forced Drupal's developers to roll their own solutions to the problems OOP is often used to solve. The developer time we need to invest in ongoing maintenance and enhancement of these custom solutions is the "Continuous Tax."
How do we balance these two imperatives? That's an excellent question -- and a lot of great answers came out of the sessions and conversations at Drupalcon Barcelona. In my next post, I'll take a stab at summarizing some of them.
Comments
Looking forward to the next post
Very interesting. I'm looking forward to the next post! :)
incremental, it's done when its done...
Nice post Jeff. I think we are all looking forward to the street cred that OOP will give Drupal. Weather its necessary at this moment in time will always be debatable. But the fact that OOP means greater mindshare for Drupal is not. Lets take this thing one step at a time...
php framework
using system like cakephp or prado?
Should help us?
Mambo going OO with cakePHP
Mambo going OO with cakePHP
http://bakery.cakephp.org/articles/view/mambo-licious
Framework and OO in D7
Over the past few months I've been looking at the OO php frameworks out there and I have yet to see one that works for all of the things we use in drupal. I think we'd end up rewriting so much of an existing one that we'd be just as well writing our own.
Yet, I think there is one huge problem that would creep in if we tried to rewrite in OO. We'd fall back from staying as close to the edge that we do. We'd spend so much time rewriting that we wouldn't be adding in new features or taking drupal in the directions so many people need it to go in.
Right now drupal not only works but works well. Why do a code rewrite because of style? Why re-architect because of style?
On the flip side I'd expect OO in drupal 7. Just not everywhere. Only where it makes sense. There are some places mentioned in the post that are obvious. There are other places it may make sense like authentication and building the user object.
In any case the possibilities leave for some fun debate and new ways to take things.
It wouldn't be just for 'Style'
As was mentioned in the post, miming OOP without extensively using the OOP features in PHP is becoming a tax on development. That was the point. I myself, suspect that this tax will increase annually as the need for OOP in Drupal increases. Ease of integration with third party applications is being pushed for, and that, at the very least, requires good solid OOP APIs for Drupal data.
use a framework
The future for large applications is definitely OO. The migration to OO php won't be so steep if we would use a framework like cakephp or codeigniter.
People
If someone comes from academia (ie. formal IT training) then it's safe to presume she is somewhat proficient in OOP. However if you have no formal IT training then OOP is strange. If someone knows OOP, then she will be able to code w/ a procedural language as well esp with the essay that shows how Drupal is OOP. The reverse is simply not true. Given this, I would be extermely cautious with what we do and who we close out. (Yes, I am one of those who do not really "get" OOP)
http://www.devx.com/opinion/Article/26776 and http://www.geocities.com/tablizer/oopbad.htm are also worth reading (I do not agree with all their points, but consider them as well).
OOP
I should just say that if Drupal had been OOP when I started, I never would have joined the project.
One of the great features of Drupal is a low barrier to entry for new developers. As chx says, relying on OOP raises the bar significantly for those of us without more formal training.
OOP learning curve and flavor
Good point chx, this would definitely increase the drupal learning curve for developers.
I'd, also, argue that straight and forced OOP is a flavor discussion. I'm all for it being offered and usable. Views uses it and that's great.
But, to force that method may not be the right way. It can increase the code base in size. There are places where, if it were used, would slow down in functionality. So, I'm not a fan of forcing it and using it everywhere.
When it comes to OOP I'm glad I'm not Dries. And, I'm glad he knows more about OOP than me.
When I joined up and started
When I joined up and started learning Drupal, I was a little surprised to hear it wasn't OO - I'd assumed it would have to be. My suggestion would be a blending - mixing in object oriented features slowly as we go. For instance, perhaps creating a node object that has some useful methods on it, or new (or current) hooks that require several parameters that change with use, could require an object instead.
Just thinking on top of my head.
I agree that going in and radically rewriting everything at once is not a good idea, but I also think that some controlled introduction of OOP, where it can seem to be an improvement, is a good idea moving forward.
It needn't be a black and white argument.
I would be sorry to see Drupal go Object-Oriented just because it can, or because the Rails/CakePHP/Code Igniter folks say it's what all the cool kids are doing.
When I came to Drupal after working with a OO, J2EE CMS for several years it took me a while to wrap my head around the way Drupal does things. ("What do you mean, no controllers?!") Once I did, though, I found that I really like the hooks system. I think it takes advantage of the things a procedural language like PHP does well, and although PHP 5's object handling support is much improved it doesn't necessarily follow that anything rewritten in an OO manner would automatically be an improvement.
These discussions often seem to start with the thesis that procedural code is always double plus ungood, and I don't think that's the case. Could some aspects of Drupal benefit from OO patterns? Undoubtedly... but let's not throw the baby out with the bathwater.
Drupal as Learning Environment (and Framework)
I was struck by the number of comments from people pointing out how much OOP might have prevented them from really understanding how Drupal works. The Drupal code base for me as been (and continues to be) a tremendous learning experience, something I'd hate to see go by the wayside for future developers. It's an interesting problem -- finding the balance between performance/complexity vs the learning curve.
That being said, I've often heard Drupal refered to as a framework as well as a CMS. Is that an accurate description? Can someone elaborate the differences between Drupal and a "true" framework, like CakePHP?
Drupal Framework
I think Drupal is already a kind of framework with modules taking the place of controllers, the templates as views and the *.install as a setup/model. It would very interesting to see how hooks and the node_api implemented in an oop aproach.
I just read that Mambo CMS
I just read that Mambo CMS is going to be rebuilt on top of CakePHP (by the way, CodeIgniter, though very lean, is so much better).
So, we are gettings into the point when many PHP apps are going to merge and converge into each other. Drupal has an unique and broad developers audience that could be used to boost its own framework, optimized for its own cms and its own runtime designer (cck).
The only "issue" is that nasty thing called "backward compatibility". To redesign Drupal in this manner will be a complete rewrite. But as dries said: "I chose not to preserve backward compatibility, because I was mainly interested in getting the technology right". I admire this attitude. So far drupal has come up with very ingenious ideas. So we're looking forward...
Create 2nd Type of Drupal
I think sooner or later we'll realize the benefit of OOP. If we don;t move to OOP, others competitor would take the benefit of OOP.
We could build a new Drupal version for OOP, so we would have 2 type/version(OOP and Procedural) supporter.
I'm writing here not as OOP user, i still learning it coz i believe it would have benefit in the future.
the future of drupal
This article is an interesting debate about the future development of Drupal. The main question is: “What is better for Drupal? OOP or PHP?†Many modern programming languages now support OOP. PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. But if you've never used a programming language before, you'll need to learn a few basic concepts before you can begin writing any code. We can compare the time and energy that must be invested for this purpose with a tax that must be paid. Hansel Heide Arizona HR Consulting.
I've been a Java developer
I've been a Java developer long enough to be completely disillusioned by the pursuit of ORM. Objects are great. RDBMSs are great. EJBs and most attempts at representing relational data in OO format is nonsensical. In the J2EE world, using/manipulating the ORM data is a pain, and drastically impacts performance (I've personally witnessed a multimillion dollar J2EE/EJB failure). Spring has alleviated this somewhat, but after 5 (?) years of getting it wrong in Java, it would be a shame to see the same happening in PHP/Drupal. I'm unfamiliar with PHP's OOP capabilities, but it I would be really disappointed if it decided to take an ORM route.
OOP freak here
My main expertise is in C++ and C#. That said, I find that the way Drupal uses the hook naming system and argument arrays is one of its strongest feature - especially in template development. You can achieve a similar feature in an OO language with interfaces, but those tend to be brittle. There's no way to append data to an existing interface without invalidating everything dependent on it. The contract by convention system in Drupal by contrast is extremely soft and malleable.
That in part has probably given the development more wind in the past as it gives the ability to incrementally try new things (hacks) before taking the plunge to formalize it in a module or elsewhere.
It's one of the few reasons I'm shying away from DNN for production sites.
Post new comment