1) Namespaces

Adding namespaces solves, in a stroke, a great many conflicts that developers tend to run into with PHP. For example, if I write a database layer class called db and YOU write a database layer called db, and I try to include another library that you’ve written that references your database layer, I’m boned. Since they’re both declared globally, this attempt at code re-use fails.

However, if I write a database layer and I decide to put it in the “danhulton” namespace, and you put yours in the “anotherlibrary” namespace, we’re fine. I refer to “danhulton\db” and you refer to “anotherlibrary\db” and all is right in the world.

Sadly, the namespace delimiter they’ve chosen is the backslash, which to my eyes just looks ODD, and also can run you into issues if you ever have to put your namespace in a string (with backslash being the escape character). Still, this is a net win for writing shareable PHP code.

2) Anonymous Functions

I got into the habit of using anonymous functions liberally in javascript, and have come to sorely miss them in PHP. Sure, you can emulate them with create_function(), but the syntax is awkward and the resource cost prohibitive. As of PHP 5.3, we’ll be able do do something a little like this:

$escaped = array_map(function($value) {
    return "'" . $value . "'";
}, array('sql', 'parameters', 'that', 'need', 'escaping'));

I’m very much looking forward to the cleaner code this will allow me to produce.

3) Ternary (?:) Operator

The ternary operator already exists in PHP, and I use it frequently. It allows you to do something like this:

$colour = ($balance > 0) ? 'green' : 'red';

Or, if you need to ensure a value is set before using it, you can write:

$entries = isset($entries) ? $entries : array();

In PHP 5.3, you’ll be able to simply write:

$entries = $entries ?: array();

Which means you can also write:

foreach ($entries ?: array() as $entry) {
    // some stuff
}

This change is excellent because, again, it leads to cleaner code.

4) Native MySQL library driver

This should be a huge win for many applications which value efficiency. (Although, isn’t that all of them?) The MySQL native driver is a full replacement for the currently-used driver written my MySQL AB. It is more efficient in terms of memory usage (storing all rows only once instead of twice), and should be just as processor-friendly, if not more. Further, there are a host of performance statistics calls that should ensure that performance debugging is much easier, and they include a function I wish had been there from the beginning: mysqli_fetch_all(). No more having to write a big while() loop with mysql_fetch_assoc(), this baby will take care of you in one line.

Now, since I’ve switched to the Kohana framework, my database functions are a lot friendlier already, so the latter function won’t specifically change how I code. But the decreased memory costs, especially for queries that return many rows, will be fantastic.

Conclusion

PHP 5.3 is going to be an excellent addition to the language, one I can’t wait for. I expect a fair amount of grumbling as we get adjusted to all the new features, and I’m rather curious to see what Kohana and other frameworks decide to do with regard to support (ideally for Kohana, IMHO, is keep KO 2.3 compatable with PHP 5.2.9, but require PHP 5.3 for KO 2.4 and 3.0). However, in the long run, we’ll have the ability to write cleaner, clearer, and less code, and that will be a fantastic advantage.

FireStick is a (relatively) simple to configure library that enables easy and low-overhead performance logging in CodeIgniter.

Performance measuring and logging is an important part of application maintenance and improvement. FireStick makes it easy to record page render times, MySQL call times, and other related information that you can use to track down performance issues.

FireStick relies on CodeIgniter’s built-in performance and benchmarking capabilities and a post-system hook. When the hook is called, FireStick logs all this information to the database for review at a later date.

Logs are split up into multiple tables based on date, with each new day’s table created automatically on the first request of each new day. All logs are added using INSERT DELAYED so as to minimize impact on the database server.

Main project page: http://code.google.com/p/firestick/
Project source: http://firestick.googlecode.com/files/firestick-1.0.zip
Installation instructions: http://code.google.com/p/firestick/wiki/Installation

I’ve been reading High Performance MySQL lately, and the very first section of the book is on profiling, why it’s a good idea, and how to go about doing it. Since I’ve deployed ComingUp out in the wild, I figured I should be profiling, too.

So I put together this little add-on library for CodeIgniter that takes the basics presented in the text and adapts them to CodeIgniter’s already well-rounded benchmark system. CodeIgniter already has total script execution time measured, total script memory consumption, and a full list of all DB calls and the amount of time they took. I just collated all of that and put it into a sensible DB logging system.

The whole deal is open source, too. GPL v3. Any CodeIgniter developer anywhere can feel free to use this, and I’d be happy if they did.

If you are using it, and you encounter any bugs or want to provide feedback, please leave a comment in the FireStick thread on the CodeIgniter forums, and I’ll be happy to address it.