Thursday, 22 March 2007

Lazy Loading of Classes Stored in PHP Session Mechanism

Frank Kleine in a post over the Stub blog tells you about lazy loading of classes stored in PHP session mechanism without_autoload ().

Frank says, in case you use the PHP session mechanism the manual has the following warning for you:

‘If you do turn on session.auto_start then you cannot put objects into your sessions since the class definition has to be loaded before starting the session in order to recreate the objects in your session.’

He informs that this also applies if you use session_start() but did not load all classes that have been put into the session in earlier requests. This can result in problems if you have a very lazy class loading and do not want to use the __autoload() feature. He gives an example of the homepage, ‘Stubbles’ and says they do not use __autoload() for several reasons. One of them is not to use PEARified class names in style of PACKAGE_SUBPACKAGE_ABSTRACTCLASS_CONCRETEIMPLEMENTATION.

He informs about a decision made earlier to have a basic interface for all classes, called stubObject. Every class implements this interface. Frank says, the trick is done with an additional class, which represents a serialized state of the concrete class. Every stubObject offers a getSerialized() method that returns a stubSerializedObject. This contains the full-qualified classname and a serialized representation of the stubObject. It also features a getUnserialized() method, which will load the class if it has not been loaded yet and then unserializes the stubObject .

He says, since the stubSerializedObject is always loaded in Stubbles, the session implementation can check if a value to store as an instance of stubObject. On a later request, he informs that when the value is retrieved from the session, the session checks if the instance to return is of type stubSerializedObject. In such cases it returns the return value of its getUnserialized() method which loads the required class if this has not been done yet.

He opines that this approach is better than using __autoload (). This is because it will load the required classes only if they are really used. If they are stored within the session but the current request does not use it the appropriate class will not be loaded.