In the second part of their look at using closures in PHP as view helpers, DevShed improves upon their original code by adding some additional classes and using them in the closures.

The best way to show you how using anonymous functions can help you to develop more efficient OO applications is with some functional, hands-on examples. With this idea in mind, in the installment that preceded this one, I implemented an extendable template system. This system could spawn view objects and render the template files associated with these objects.

In this second part of the (two-part) series they include "Serializer" and "FileHandler" classes and show how to use them inside of the closures to lazy-load in data from an external file and work with it as serialized content.

Martin Sikora was working on an application that used a large dataset (in an array) and found some interesting things in regards to PHP's resulting loading time and saving time in four different types of arrays.

Recently I was dealing with precessing and storing large arrays in PHP (around 100 000 items) and I found out some quiet surprising facts that are very useful in performance critical applications. [...] When I started looking for some benchmark I found article Cache a large array: JSON, serialize or var_export?. That is really good but I wanted to compare a few more things.

He tested with four different array types including associative with an integer value and numeric index with a string value at sizes of 10, 100, 1,000 and 10,000 items. He ran his tests with the json methods, serializing them and a var_export. There's graphs of his results for each included in the post with some interesting variations between the different array types.

Gonzalo Ayuso has an interesting new post today looking at how to go cross-technology in your application and store your PHP sessions in a basic Node.js instance.

We use sessions when we want to preserve certain data across subsequent accesses. PHP allows us to use different handlers when we're using sessions. The default one is filesystem, but we can change it with session.save_handler in the php.ini. session.save_handler defines the name of the handler which is used for storing and retrieving data associated with a session. We also can create our own handler to manage sessions. In this post we're going to create a custom handler to store sessions in a node.js service.

He includes the full code you'll need (also here on github) to make a custom session handling class on the PHP side and some simple unit tests done on the Node.js side to ensure for proper handling and garbage collection.

On Elated.com today there's the fourth part of their series looking at object oriented programming in PHP. This time the focus is specifically on autoloading classes, making objects into strings (serialized) and introspection.

If you've read all the articles up to this point then you're already familiar with the most important concepts of object-oriented programming in PHP: classes, objects, properties, methods, and inheritance. In this final (for now, at least!) tutorial in the series, I'm going to tie up some loose ends and look at some other useful OOP-related features of PHP.

He looks at each of the three topics above and includes code for things like a simple autoloader, object serialization, using sleep/wakeup and an example of using functions like get_class, get_class_methods and get_object_vars to do introspection on your classes and objects.

Phil Sturgeon has posted about a utility he's released that can help convert data from one state to another such as arrays to JSON and XML to CSV - php-format.

Convert between Array, Object, JSON, XML, CSV and Serialized data and back again easily. I'll add a few more types like YAML when I can be arsed to work out PECL for MAMP.

There's a code snippet in his post showing the conversion of an array to JSON then to XML then back to an array. The code is pretty simple to follow with "to" and "from" methods for each format making it simple to extend for your own uses.

In looking for a better way to handle serialized data (than the usual serialize) Ilia Alshanetsky discovered an extension called Igbinary:

As I was reading docs on Andrei's new memcache extension (memcached) I came across a binary serialization extension called Igbinary written by Sulake Dynamoid Oy. This extension promised much more optimal serialization routines by using binary, rather then a clear text format. Sounded, good so I decided to run a few benchmarks on it.

He uses several different sizes of files to run his tests and found that, while it is just a bit slower than the normal serialization, the compression rate that's about fifty times smaller than the usual. The extension also offers a "compact_strings" parameter that allows for even more compression of just string data.

As you can see the serialization speed is pretty amazing, once your serialized data set is in excess of 100bytes, you can expect nearly 2x improvement with a ~30% data set reduction with igbinary. I think we got a winner!

Andrea Giammarchi has posted a new item to his blog looking at freezing and unfreezing objects and variables in PHP apps. Specifically he points out a few gotchas to watch out for.

PHP has different in-core callbacks able to help us with daily deployment, debug, improvements. At the same time, PHP is loads of intrinsic "gotcha", too often hard to understand, hard to explain, or simply hard to manage. One common problem is about debug, caching, or freezing, and the way we would like to debug, cache, or freeze, variables.

He presents the problem - serializing variable information to "freeze" it and how recursion can cause problems down the line. He looks at the two different kinds of recursion (recursion and recursion by reference) and, after looking at a few possible solutions to fix things, eventually comes down to a way to remove the recursion "without losing it".

As mentioned in a recent tweet of his, Andrei Zmievsky has release the latest version of the memcached extension with an interesting new feature:

Just released PHP memcached extension v0.2.0, now with JSON serialization support: http://pecl.php.net/package/memcached/

This extension can be adding into your PHP installation to allow direct interaction with memcached servers via the libmemcached libraries and the server's API. You can grab the most recent version of the extension from this github page.

David Goodwin has a suggestion for those developers that think storing objects in a database is a good idea - don't do it!

Short answer: DO NOT DO IT. Longer answer:....I hate seeing serialized PHP objects within a database.

Some of his reasons include:

• It's difficult to index/search - you'll probably need to use a regexp.
• PHP Specific - good luck doing much with the data in a.n.other language
• If the objects are large, you're likely to have a text or a blob field - this will suck from a performance point of view (at least in MySQL)
• Why bother storing serialized objects in a database - surely to the filesystem would be better?

Several opinions are expressed in the comments including some that agree with David and some that still defend the idea.

Fabien Potencier has a new post about a strange and hard to track down bug he was experiencing with serializing a symfony form - it was throwing a PDO exception.

This exception is thrown by PDO because PDO instances are not serializable for good reasons. But it is weird because the sfForm class does not depend on PDO. How is it possible?

After some poking around, he noticed that this was only an issue for those with sessions stored in the database (that's where the PDO comes in). The problem came with the validation error class - it extends the exception class and, because of how the error handling serializes the exception, it tries to serialize the PDO connection that's in the stack trace too.

His solution is to use a Serializable interface to define exactly what you want serialized and passed back out as the error to the rest of your script.