PHP is able to automatically serialize most of its variables to strings - letting you save them into storage like $_SESSION. However, there are some tweaks you have to know to avoid exploding .php scripts and performance problems.

He gives some code snippets showing the serialization of variables and objects and points out a few things that can't be effectively serialized (like resources and closures). The mentions the "__sleep" and "__wakeup" magic methods for automatic class serialization and mentions the Serializable interface that comes built in to PHP.

Today I ran into a problem where my PHP Application would throw this fatal error: "Fatal error: Exception thrown without a stack frame in Unknown on line 0". Which is so much fun, because it doesn't have a line number, so I had no direction as to what exactly was causing the problem.

He found a blog post that helped him track down the issue that, as it turns out, with serializing objects into the session and an error in the __sleep method.

The objects themselves have a number of injected dependencies. It includes using the PHP magic methods __sleep and __wakeup to manage serialisation. It also discusses mechanisms for re-injecting dependencies on wakeup via a method that maintains Inversion of Control (IoC).

He uses a user object based example that has an injection needed to load in the user's usage history. He includes the code to define the classes, create the objects via a dependency injection container and performing the sleep/wakeup actions with the dependencies coming out intact on the other side.

Magic functions are an important part of the numerous improvements and additions that were introduced originally in PHP 5. They can be extremely handy when it comes to simplifying the execution of complex tasks. [...] In this fourth chapter I'm going to examine closely the "__sleep()" and "__wakeup()" functions, which are called automatically when an object is serialized and unserialized respectively.

In their example code they add the __sleep and __wake functions to the class they've been developing to output a string when the object is manipulated. These methods are automatically called when a serialize/unserialize function call is made on the object.

Terry Chay made some remarks to my last blog entry about a solution for lazy class loading without using __autoload(). Some of his statements seem like I explained my implementation not good enough leading to wrong interpretations. In this blog entry I'll use some of his statements to take a deeper look into my implementation and show that he has drawed some conclusions which I want to disprove.

He goes back and corrects some of what Terry has said in his response, including showing a more detailed version of him implementation. Be sure to check out the comments for the post, though - Terry comes back and clarifies some of the comments he'd made including the framework talk and changes of perspective having seen the new code snippet/information.

They start with a look at defining self-saving objects with their ObjectSaver class developed earlier. Building on that reminder, they integrate the "__sleep()" and "__wakeup()" functionality to handle calls immediately before and immediately after the handling of the object. They then use this new functionality to create persistent objects, capable of maintaining values across page requests.