Architecture

This article is also available in Serbo-Croatian

This article is also available in Dutch

There has been much discussion of late in Drupal about Object-Oriented Programming. That's not really surprising, given that Drupal 7 is the first version that has really tried to use objects in any meaningful way (vis, as something other than arrays that pass strangely). However, too much of the discussion has boiled down to "OMG objects are inflexible so they're evil!" vs. "OMG objects are cool, yay!" Both positions are harmfully naive.

It is important for us to take a step back and examine why one particular programming paradigm is useful, and to do that we must understand what we mean by "useful".

Programming paradigms, like software architecture, have trade-offs. In fact, many of the same methods for comparing architectural designs apply just as well to language design. To do that, though, we need to take a step back and look at more than just PHP-style objects.

Warning: Hard-core computer science action follows. If you're a coder, I recommend getting a cup of $beverage before continuing, as it could take a bit to digest although I've tried to simplify it as much as possible. There's fairly little Drupal-specific stuff here so hopefully it should be useful to any PHP developer.

As anyone who has followed my past work knows, software architecture is a particular interest of mine. I find the subject fascinating, but my interest is not entirely selfish.

Understanding architecture, and the trade-offs that different architectures imply, is an important part of any software project. Whether you're discussing a Content Management Platform like Drupal, a language like PHP, or a particular web site, having a solid understanding of the "big picture" is crucial not only for building the system right in the first place but for communicating that architecture to others.

To be able to speak and think about the design of your system properly, though, you need to understand the trade-offs that come with it. There is no such thing as a free lunch, and designing a system to be powerful in one way invariably tends to harm it in another. It is important to know what your priorities are before you start building; and in a distributed collaborative environment like Drupal to all agree what those priorities are, at least to a large extent.

Let us therefore examine those priorities and the trade-offs they require.

A few weeks ago, I and several others helped some friends of ours pack up their apartment into a truck in preparation for moving cross-country from Chicago to New York. It was, as such moments generally are, bitter sweet. It's always a good feeling to help out a friend, but when you're helping them get further away from you it's not as pleasant.

Of course, me being me, what struck me most about the whole process was how well it served as a model for software development and project management in general.

The "smallcore" debate has heated up again of late, with all its various tendrils. However, I still see a lot of the same misunderstands that I've been seeing for weeks. That can only mean one thing. Time for me to write something. :-)

I do not consider myself a "smallcore" advocate, for one very simple reason: It's horribly misleading. Allow me to repeat what I already said there:

The goals of the "smallcore" movement can be obtained without removing one single module from Drupal core.

Instead, I look at the question of Drupal's future direction from a simple architectural perspective: Is Drupal going to be an additive system, or a subtractive system?

Just when you thought it was safe to go to DrupalCon, here comes... schedule change!

It turns out there was a late cancellation, so the DrupalCon Paris team has asked me to fill in with Drupal Design Patterns on Wednesday afternoon.

If you write modules for Drupal, you want to be there. Although we'll be approaching the subject from a slightly theoretical slant, the main thrust will be how to write code that other developers will understand quickly, that they'll be able to extend, and how to not reinvent the wheel by leveraging existing solutions and approaches.

Via Planet PHP I stumbled across this article decrying Singletons. It's not a new argument, really, but one of the comments pointed me toward a Google Tech Talk video entitled "Global State and Singletons". To be honest I don't agree with everything said in either the article or the video, but both are spot on about the problems of global state, something I've lamented before in relation to testing.

That is especially relevant now, as we consider the question of Handlers in Drupal. Why? Because the most controvercial part so far, the environment variable, is designed to address exactly this problem, a problem that is currently prevalent throughout all of Drupal.

Permit me to explain.

Some time ago, I posted an RFC for pluggable "system handlers". It generated a fair bit of feedback, nearly all of it positive. That was followed up with a presentation in Szeged, which generated even more positive feedback.

So what's happened since then? Well, a fair bit. There's working code, but there are still some key gotchas to sort out. That gives us a couple of options for how to proceed, for which I would like feedback, particularly from core developers and maintainers. (Dries, webchick, this means you! :-) )

Recently I've been talking up various ideas for pluggable subsystems in Drupal in IRC and the other usual haunts. Ideas have been percolating in my head, but so far I have been remiss in actually writing them down. Yesterday, however, I had an epiphany to solve the primary issue I was trying to work out, so I present a hopefully workable RFC (for real, not IETF version) for pluggable subsystems in Drupal.

I am posting this over to Planet PHP as well to invite commentary from those who aren't already embedded in the Drupal mindset. :-)