Marco Tabini, of php|architect magazine fame among other things, has been openly disappointed at the death of PHP 4. Not because he likes PHP 4, but because of the "OMG you're discontinuing something that everyone's still using!" argument.
I like your magazine, Marco, but I have to disagree with you on this one. :-)
I've just posted another "Data API What If"-style article over on http://groups.drupal.org/. I figured that was more archiveable than my personal blog, but I wager more people read Drupal Planet than a specific g.d.o group so I'm posting the link here as well in a blatant bit of self-promotion. :-)
I am also posting this over to Planet PHP, in case any other exPHPerts have words of wisdom to offer. Hi guys!
Earlier this week, the PHP team released PHP 4.4.8. Baring any major security holes between now and August 8th, it will be the last release of PHP 4. Ever.
We are also one month away from the GoPHP5 deadline, after which any new releases of almost every major PHP project will require at least PHP 5.2. If you or your web host is running an older version, you are going to run into problems.
The future is neigh. Is your server ready?
The day is nearly upon us! Drupal 7 will open up developers to PHP 5 functionality when it is released next year. Already, there is talk of how, and if, to leverage PHP 5's object handling now that we don't need to deal with the weirdness of PHP 4's object model. Of course, because it's Drupal, our army of performance czars want to know just what the cost is for object handling, and especially advanced object magic like __get(), __call(), the ArrayAccess interface, and so forth.
So let's find out. :-)
One of PHP 5's coolest features is the Standard PHP Library, or SPL. If you're operating in an OO way, SPL is a great way to easily leverage a huge amount of functionality.
Of course, the main problem is that the official documentation on it sucks. At best it points to an off-site series of class hierarchies. (Technically it's not off-site, but not internal to the manual.)
So it's been a week since DrupalCon, which means I'm kinda sorta caught up enough to write about it. Hooray!
As with DrupalCon Sunnyvale, I came away with one conclusion fixed in my mind: The Community is Drupal's greatest strength. Virtually everyone upholds a strong community and open source spirit, and will gladly talk to you for hours about subjects both on topic and off, with or without beer (free or otherwise).
But enough about how cool we are. On with the rundown.
A ran across this article recently making the rounds. In it, the author discusses spending 2 years in Ruby on Rails land before finally giving up and coming home to PHP, wiser for the experience. It's a good article, but one thing in it really raised the hair on my neck.
There has been some discussion recently, in IRC, issue queues, and blogs, about the Drupal 7 database API and its impact on supporting different database engines. While I am still trying to avoid large amounts of public distraction, especially when we're supposed to be trying to get a Drupal 6 beta 1 out the door, I feel it's important to get a few points cleared up lest they lead to confusion later.
PHP 5, however does include lots of "magic" capabilities, some in the object model directly and some via SPL Interfaces, that, if used properly, can make up for a lot of that lack of dynamic capaibility. A favorite of mine is the ability to add methods to a class at runtime.
What? You didn't know PHP can do that? Well, that's because it can't. However, we can simulate it pretty closely if we're careful. Let's see how.
Are you tired of hearing me talk yet? If not, why not come work for Palantir.net? We're looking for a PHP/Drupal programmer and a web developer/themer. Benefits include a full time position at a small business in Chicago, working on sites for higher education, not-for-profits, and other non-evil clients, a company issue Nerf gun, and access to the company Wii. And getting to work with Larry! Who could ask for a better job?