I finally decided to get around to doing something about my site, so I've made a front page for it which is better than a straight redirect onto the blog. Hopefully it's reasonable.

I've been learning a bit more recently about the internals of PHP, and how to write extensions for it. I've been practicing by doing a bit of work on a Cairo wrapper that was started in the Google Summer of Code last year and until now has been mainly looked after by Elizabeth Marie Smith. She's put up with many, many newbie questions from me and so I've learned a lot while doing it. It's now at the stage where it'll run the eZ Components Graph component without too much complaining. It has a dual procedural and object-oriented API, so it should manage to run most things that use the existing cairo_wrapper extension. Thanks to all the regulars on #php.pecl and #php.doc on EFNet, and #php-gtk on Freenode for putting up with me while doing this. I've also written a quick wrapper for Tokyo Cabinet for the DBA extension in PHP which with a bit of luck will get committed to PHP6 some time soon.

In other news, I've been occasionally helping in the maintenance of Jubilee and An Sulaire, the two Sgoth Niseach boats I go sailing on occasionally. Hopefully they'll be going back in the water soon and we can get some sailing done. I'm looking forward to it.

register_globals is going way in PHP6.  That is fine with me.  Super globals are cool and I have taken to using filter_input_array these days anyhow.  However, our code base is now 10+ years old at dealnews.  Most of the forward facing code was completely rewritten in the last couple of years due to architecture changes.  Many new projects had register_globals turned off via php_admin_flag in Apache.  So, that area is not that big of a problem.  However, our internal admin areas have not all be rewritten because, well frankly, they still work.  Yeah, stuff written for PHP4 in 2000 is still working.  KISS helps a lot with that.  But, this code, somewhere in there, may still be relying on register_globals.  Now, we could go line by line and try and fix it.  But, it seems like a program could be written to do this job.  I mean, I use jEdit and it can highlight unset vars using the PHPParserPlugin just fine.  I bet Zend IDE can do the same.  Has anyone written such a tool for the command line?  There will be false positives I know.  Things like passing a variable by reference to a function would look like a use before set.  But, I can deal with those if I don't have to go line by line through tons of old code.  What would the rules look like for such an animal?  This would be a great project to get off the ground before PHP6 hits.  Ideally you could provide a list of variables for it to ignore.  We have some globals we set up in prepends and includes.

Damn, I didn't really have the time to look at this version yet, but reading now the new features list, it looks like the most interesting PHP version ever.

I mean closures and lambda functions in PHP, I have been waiting for this for too long. Fileinfo, a very useful extension that I always had to compile is now bundled. Changes to the ternary operator ?:, hehe. A new MySQL driver which should eat less RAM ! ext/intl looks amazing too.

Well, this looks really great, I still have to test this (especially the anonymous functions) and see if it is as cool as it sounds.
Namespaces look weird with their antislash syntax tho... :/

Update : actually, given the long new features list, I start to wonder why they didn't call this version PHP6 ?

Yeah, that’s about all this post will be. I read an article from IBM developerworks on the upcoming 5.3 features, and something got my dander up: closures.

I first got acquainted with closures in Groovy last year, and love them. They make sense. The syntax is pretty easy, and feels natural in the language. Not so in PHP. Once again, inconsistencies are not just legacy issues in PHP – they are created anew for us to deal with for years to come.

Look at the example here:

class Dog
{
 private $_name;
 protected $_color;

 public function __construct($name, $color)
 {
  $this->_name = $name;
  $this->_color = $color;
 }

 public function greet($greeting)
 {
  return function() use ($greeting) {
   echo "$greeting, I am a {$this->_color} dog named
   {$this->_name}.";
  };
 }
}

Given that ‘anonymous function’ inside the greet() method is a closure, WHY NOT NAME IT THAT? The PHP Reflection API was updated to include a “getClosures()” method, but what would you get? They keyword “closure” doesn’t exist, but could have. Instead we now have the keyword “function” looking like two different entities – it looks like a function call when used with the () directly after it, and also has its traditional function fname() syntax still available.

I have to teach this stuff, and being explicit with a closure keyword would have saved a lot of headaches to come in explaining this stuff to people. Additionally, it would have been less to type.

Compare

return function() use ($greeting) {
 echo "$greeting, I am a {$this->_color} dog named {$this->_name}.";
};

with

return closure($greeting) {
 echo "$greeting, I am a {$this->_color} dog named {$this->_name}.";
};

What’s more explicit, easier to understand, and fewer characters to type? Given the recent namespace separator debacle (using \ as a namespace separator, and justifying it because it’s “fewer characters to type”), I can’t really understand the rationale behind the closure syntax.

To be fair, the closure syntax RFC was up at http://wiki.php.net/rfc/closures and I didn’t comment in time. So, I guess it’s all my fault. Beauty and elegance have never been PHP’s strong suit, but it seems people went out of their way to make this unintuitive and bulkier than it needed to be. :/

On a more broad note, I really think the bulk of these changes (closures, namespaces, etc.) should have been put in php6 only, not in the 5.3 series.  I understand the need for testing and such, but we’re implementing new functionality and defining how it is expected to work based on the current PHP5 Zend Engine.  Whatever useful changes that might make a PHP6 faster/better/whatever can’t easily be implemented because the ‘new’ features are all dependent on a core engine that’s already 5 years old, which it itself was built with an eye towards backwards compatibility to PHP3.  Strategically, it just feels like the wrong move.  But hey, what do I know, right?  I can’t write C code patches, so my views don’t really have much weight, do they?

Truncated by Planet PHP, read more at the original (another 12269 bytes)

Truncated by Planet PHP, read more at the original (another 12269 bytes)

In technology years, I am an old man. I came to PHP in late 1998 while in college. Before that, I mostly developed in perl based on samples from the Perl Cookbook. I mean, where else were you suppose to start, right? Within a month of using PHP, it became abundantly clear that developers could become immediately productive by prototyping and building systems in PHP far faster than any other language I had encountered to date. And yeah, this was PHP3 – the other odd numbered release. If I recall correctly, the most difficult part of PHP at that time was making sure it would compile and install correctly on Redhat 5 and 6.

Any of these version numbers bringing back nostalgia to you developers?

Kind Words

The irony right now, is that most developers who have since embraced PHP5 are now treating PHP4 just as they would the death of a person that they disliked in life. For years (myself included), we’ve scoffed at PHP4 code. And why not? It’s so easy to spot. It generally looks as though it should come with a side of marinara and garlic toast. Most applications written on the platform started out clean, but then over time decomposed into a mess of tangled and indigestible code fragments. Revisiting these projects to add new features, or fix bugs (for the unluckiest of contractors) soon always began with a series of 4 letter expletives. It was these experiences that had us looking towards the future, the PHP5’s, PHP6’s, PHP10’s.

So it has come, after years of cursing PHP4 by name, just as we would a villain in life, we assemble in this blogosphere to pay homage and eulogize PHP4 with the best of words, despite what he might have done in his old age. I’m sure the messy codebases of years past have not died with it, but at least there is a movement (much like a ball rolling down a hill, or an avalanche), to embrace PHP5’s OO model, unit testing, time tested software patterns and community accepted best practices.

PHP4: you slipped into a coma at the end of last year, and today (8-8-8) you died. I’ll recall some of the more interesting times I spent with you.

What did I do with PHP4?

The Ochsner Medical Center Wayfind and Directory Assistance Application

Around early 2003 I was contracted to build an application for a network of kiosks to display directory assistance and mapping at a relatively large hospital in New Orleans. Without going into all the massive details, this application took large jpg images with points mapping in a MySql database representing the hallways of the hospital on all 11 floors as well all all of the offices of all of the doctors. A flash application on the kiosk (which was touchscreen), would then ask the server for a specific doctor name. PHP would then (via all the great geometric math functions), would produce an XML file with all of the point to point animations that flash then had to do. PHP would also walk down all possible physical routes, going to all possible elevators trying to find the shortest route. It did this in real time. The database was updated often. It rocked.

Tulane Career Services Sign-in Computer

When I worked at the Tulane CSC, I was tasked with replacing our sign-in book with a computerized sign-in system. For this, we got a list of all the students from the Registrar, and bought a USB card scanner. Thankfully, there were some numbers in that little black strip that I could pull out of the Registrar database and mark the student as having visited the center in real time, without doing anything more than scanning their card. The card reader basically wrote to STDIN of the computer, so as long as the web text field had focus (enforced with JS), the system would work flawlessly– assuming the person with the card was in the system. If they weren’t they had to visit a web form, which sucks for them, but all in all, the system worked well.

Email Tracking System (Mostly for The Netcom Group & Starwood)

This was an interesting project. Given a list of conference attendees (sometimes 20 sometimes 5000): craft an email that had clickable and trackable links (that could get past spamassassin, hotmail filters, yahoo filters, aol filters, etc.), trackable open images that will redirect them to the conferences group rate hotel site for booking.

Each email was crafted based on that email list which was loaded into mysql by a php script. That php script then created and registered each individual link into th

Truncated by Planet PHP, read more at the original (another 1884 bytes)

I woke this morning with a grin. Nope, nothing to with the Olympics; PHP 4 is dead and by that I mean it is no longer supported - no more official security updates for PHP 4 - or backports from PHP 5 or PHP 6.
The last release of PHP 4.4 occurred yesterday.
Why is this important - and why am I grinning?

PHP 5 has improved support for Object Oriented Programming, PDO, numerous performance and security enhancements that make continuing to maintain or develop PHP4 specific code a mugs game.
The enhancements in PHP 5.3, which is scheduled to be released in October, and those in PHP6 make it all the more compelling to move from PHP4.
If you are a developer and are unaware of this or are clinging on to PHP4 for dear life, you’d do yourself a favour by evaluating all options open to you - including a change of career.

The hosting market may be slow to catch up but remember this: there will be no more security updates for PHP4 and there are security enhancements in PHP5. Compelling reasons to ask your hosting provider if they do PHP5 hosting. Web hosts who are dedicated to supporting PHP 5.2 or later are listed on the gophp5 website.
Blacknight are the only Irish hosting company listed there.

Ivo Jansch, CTO of iBuildings painted a fairly bleak picture a month ago regarding continued PHP4 usage; poising the question “what if there’s an exploit for PHP4 and the bad guys are waiting until after 8/8/8 to make malicious use of it”. This is just scare-mongering but he does make a valid point, after today it will take longer than usual, if at all, for a fix against such expoints to be made available. So if you’re in business it would be wise to consult with your hosting company ASAP.

If you don’t speak German, you’ll probably be less interested, but as I blogged today in my German blog, I will author a book about PHP6 for entwickler.press. This is the second book I’ll do with them and I am really looking forward to this, as entwickler.press is a great team to work with. When? [...]

I’ve putzed around with it before, went through some example code, etc., but yesterday picked up the “Programming Erlang” book from Pragmatic Programmers.  Might still return it if its too dense, but doesn’t seem to be so far.

The biggest takeaway I have is that Erlang is good for concurrent programming because of it’s ’shared nothing’ approach (my words, not theirs).  Actually, there’s quite a bit on Erlang at Wikipedia.  For example: “Process communication is done via a share-nothing asynchronous message-passing system: every process has a “mailbox”, a queue of messages sent by other processes, that are not yet consumed.“  What does that sound like?  How can I tie this in with PHP? 

PHP and Perl for sure (and I believe Python and Ruby, though I’m not sure) use the “shared nothing” approach in web development (for the most part, mod_perl notwithstanding).  This has demonstrated that it’s very easy to ’scale out’ web sites that need it usually by simply adding more front-end web servers.  Scaling out the database does become a more difficult bottleneck problem, but it’s not impossible.  Contrasting this with the complexities that Java has when trying to ’scale out’ applications.  This isn’t saying Java apps can’t scale.  However, specifically in the web domain, the Java code I’ve come across has tended to use threads for many problems, and threadded applications are harder to ’scale’ across multiple machines.  Again, not impossible, but harder to manage.

Should the VMs just get more advanced and manage the threads across multiple cores (or multiple physical machines) for you behind the scenes?  Or should programmers be required to think about app design fundamentally differently than the traditional ’spawn multiple threads’ approach that Java (and others) take?

This is not me necessarily saying that PHP is the be-all and end-all.  It’s not - it certainly has its share of problems.  But I’m finding it interesting that one of the key tenets of Erland - shared nothing processes - has been a key factor in what’s allowed PHP to become as dominant as it has.  This is also what allowed Perl CGI apps to become as popular as they did in the mid-to-late 90s as well.  Process and queue management in PHP6 would, imo, make it a viable contender to Erlang for the ‘concurrent processing’ market.  The ‘o’ in the ‘imo’, however, is based on a very early understanding and basic experience with Erlang - that ‘o’ may change in the next several months. 

What are your thoughts regarding the pros and cons of PHP compared to other languages/platforms?

 Did you like this post? Buy me a hot chocolate!