PHP

Let's be honest, I spend a lot of time at conferences. Over the past 2 years or so I've averaged more than one speaking engagement at a conference per month, including a half-dozen keynotes. I've also helped organize several conferences, mostly DrupalCamps and DrupalCons. I'd estimate conferences make up more than a third of my professional activity. (Incidentally, if someone can tell me how the hell that happened I'd love to hear it; I'm still confused by it.)

As a result I've gotten to see a wide variety of conference setups, plans, crazy ideas, and crazy wonderful ideas. There are many wonderful things that conference organizers do, or do differently, and of course plenty of things that they screw up.

I want to take this opportunity to share some of that experience with the organizers of various conferences together, rather than in one-off feedback forms that only one conference will see. To be clear, while I definitely think there are areas that many conferences could improve I don't want anyone to take this letter as a slam on conference organizers. These are people who put in way more time than you think, often without being paid to do so, out of a love for the community, for learning and sharing, and for you. Whatever else you may think about a conference or this list, the next time you're at a conference take a moment to find one of the organizers and give them a huge hug and/or firm handshake (as is their preference) and say thank you for all the work that they do.

Over the last few years, one of my foci has been bringing together the PHP community and taking the time to celebrate the PHP Renaissance. That effort has taken me all around the world, from Paris to Toronto to New York to Costa Rica to New Zealand. And this summer it's taking me to the Midwestern US as part of the Crafting Code Tour.

Ever heard of functional programming? Not procedural programming, but actual functional programming. Probably, as some fancy academic thing that no one really uses, right?

Did you know you can do it in PHP, too? It's true. In fact, I'll be speaking about it four times in the next couple of weeks!

Recently, Anthony Ferrara has been posting a periodic "Beyond" series about software design philosophy. Some in particular have hinted at concepts I've been pondering as well. With his blessing, therefore, consider this a continuation of that series.

PHP 5.4 is not exactly new, but it's finally starting to see actual usage by a decent number of people. Its most notable new feature is Traits, which in PHP are implemented as, essentially, compile-time copy-paste. Conceptually, though, they're a way to mix functionality into a class without using inheritance, and without requiring a separate distinct object for composition. (At least in PHP; the term "trait" appears in other languages for similar but subtly different tools.) That's not to say that they're a surrogate for composition; they most certainly are not. They serve a different purpose, that is, providing code for a class to reuse without using inheritance.

Recently, I was reading an article discussing the implementation of inheritance, such as it is, in Go, Rust, and other new-wave concurrent languages. (Thanks to twistor for helping me track down the link.) It made an interesting point that crystallized for me why it is I am so excited about traits. Specifically, it noted that there are not one but two kinds of code reuse: interface reuse and code reuse.

Recently I had an email conversation with someone about PHP, and how to market a new product to PHP developers, specifically through getting major PHP projects to adopt it. The details of that conversation are not really relevant, but in the course of the discussion a familiar topic came up that I feel warrants a blog post of its own.

There is a schism in the PHP community. A big one. One so big that I don't think many realize it's there, because the gulf across it is just so wide. See, there's not one "thing" called a "PHP Developer"; there are two, and they are so unalike that I have never seen them really see eye to eye.

Well, I've gone and done it. I've managed to setup my most intense conference schedule to date. This fall I will be appearing at no less than five conferences, speaking at least four of them.

If you're into Stalking Crell, here's where you'll find me around the globe this fall.

Earlier today, I posted a brief tweet (isn't that redundant?) about return values in PHP (or really, any language). Originally it was about return values from functions (such an exciting topic, I know), but it ended up generating a fair bit of lively conversation, as well as a patch against Drupal 8. So lively, in fact, that I think it deserves more than 140 characters.

New rule:

If your function returns a collection, its null value return must also be a collection.

And so 2012 draws to a close. The world didn't end, to the disappointment of many. In some ways it was an eventful year, in others rather ho-hum follow-ups to the excitement of 2011.

In the Drupal world, though, 2012 will go down as the year Drupal finally began replacing NIH with PIE. Compare Drupal's 8.x branch a year ago with it today. A year ago, we had one class of 3rd party PHP code, in an uninteresting corner of the update system. Today, it contains 3rd party code from no less than five different projects: Symfony, Doctrine, Guzzle, Assetic, and Twig. Those libraries are included via Composer, the new and ground-breaking PHP-library-management-system-that-actually-finally-works. Code from at least one more should be landing soon.

Drupal developers, working on Drupal, have contributed to a number of other projects, including Symfony and Symfony CMF, and because of the degree of code sharing happening in the PHP world now have indirectly contributed to a half-dozen other major projects, too. Drupal 8, aside from the technological advances it will offer over Drupal 7, also represents perhaps the largest cultural shift in Drupal or PHP history.

Are you ready for 2013, Drupal? Really?

The private variables debate is going around the PHP world again. Brandon Savage posted a pair of articles pointing out the perils of private variables, boiling down mostly to them making extension infesible or impossible. Anthony Ferrara replied with his own article, arguing that the real problem is using inheritance in the first place rather than composition. I figured I'd weigh in on my own blog rather than in a comment. :-)

As an academic matter, I agree with Anthony. Composition and interfaces are more flexible than inheritance. I've been preaching the interface gospel within Drupal almost as long as I've been preaching Dependency Injection.

For Drupal 8, we want to bake REST support directly into the core system. It's unclear if we'll be able to go full-on hypermedia by the time we ship, but it should be possible to add via contributed modules. For the base system, though, we want to at least follow REST/HTTP semantics properly.

One area we have questions about is PUT, in particular the details of its idempotence requirements. For that reason, I'm reaching out to the Interwebs to see what the consensus is. Details below.