If you have a closer look at the code, front.php has one input, the Request, and one output, the Response. Our framework class will follow this simple principle: the logic is about creating the Response associated with a Request. As the Symfony2 components requires PHP 5.3, let's create our very own namespace for our framework: Simplex.

He puts the main front controller in just the "Simplex" namespace but adds in others for the controllers and models. He also updates his Composer configuration to create some PSR-0 autoloading.

Recently there has been a rather heated and intense discussion on whether the PSR-0 autoloader "standard" should be included as part of the PHP core (in ext/spl to be exact). I've tried to stay out of the discussion and have successfully done so. Until today. I feel that there's something that's been missing to the discussion. So rather then posting this to the internals list, I feel it's better served by a blog post on the subject. So here's my take on it.

As mentioned, he's not in favor of the inclusion for three different reasons:

• It's inconsistent with current PHP functionality and would bias development one way or another
• It's not an actual standard, just a loosely defined practice based on functionality already in place
• There's noting for core to gain by adopting it and could cause problems trying to make things fit a one-size-fits-all solution.

Building on the foundation from the previous screencast, he shows how to enhance it and allow it to autoload based on an autoloader defined in a "stub.php" file.

You can grab the complete source for this screencast over on github.

The key issue was that 5.3.7 accidentally broke is_a() for a reasonably large number of users. Unfortunately the fixup release 5.3.8 did not address this 'mistake', and after a rather fruitless exchange I gave up trying to persuade the group (most people on mailing list), that reverting the change was rather critical (at least pierre supported reverting it in the 5.3.* series).

This new issue was causing some strange errors to pop up in his code because of a parameter type change in the is_a call, updating the first parameter to be an object instead of a class name. The is_a() call sends its requests to __autoload in some cases and the string->object mismatch of those parameters causes errors to be thrown. His workaround is, in your checking, just be sure to call an is_object first before passing things off to be is_a() checked and autoloaded.

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.

Image processing in PHP is a necessary evil but is needed more often than not in just about every web application. With the various preferences in image processing libraries (think ImageMagick, GraphicsMagick and GD) it is difficult to find a library that provides a unified object oriented interface as well as implementing the general tasks in a simplistic fashion. Imagine is an open source image manipulation library built with PHP 5.3 that implements an object oriented interface to ImageMagick, GraphicsMagick and GD

Mike gives a quick sample script that uses SPL autoloading to pull in the classes as they're needed (with the "imagineLoader" method) and make a basic thumbnail from a PNG file.

I'm not yet sure what is the best approach to use this loader. When I started looking for examples I sent a small tweet which was replied to by Stefan Koopmanschap as he used this class loader in one of his own libraries. What he did is to include the class/namespace registering code in one of the central classes of his library. If you take a look at my code you will see the same approach.

He decides that the library itself shouldn't try to do the autoloading itself. It should always assume that there's something in place to load the files/classes it needs to get the job done. The UniversalClassLoader is prefect for this but, in his option, shouldn't be a part of an application's functionality (see his commit here removing the autoloader).

During the past week, I've been looking at different strategies for autoloading in Zend Framework. I've suspected for some time that our class loading strategy might be one source of performance degradation, and wanted to research some different approaches, and compare performance. In this post, I'll outline the approaches I've tried, the benchmarking strategy I applied, and the results of benchmarking each approach.

His testing included a baseline of the Zend Framework 1.x series loading, a naming/class standard following the PEAR standards and class mapping with file/class name pairs. He includes his benchmarking strategy and the scripts he used to run the tests (on github here). He ran them both with and without opcode caching to give a better overall performance view.

I was trying to load a Front Controller plugin which resides in app/modules/my_module/controllers/plugins/ and not in the '�usual'� lib/My_App/Plugin/. I want this plugin to be called in every request and I want the plugin file to be under it's '�parent'� module.

To solve the problem he added a path to the Zend_Application_Module_Autoloader as a resource and registered it in the front controller. He includes some code to show how it works - a simple bootstrap with two _init functions, one for the news autoloading and another for plugins.

Modules are natively supported in Zend Framework, but their implementation is not conducive to flexible autoloading nor the use of namespaces in PHP 5.3. There may be a few contributors out there that will defend the current implementation of module autoloading, but throughout the development lifecycle of the current Model-View-Controller implementation in the framework, poor design decisions have made working with modules less flexible and more frustrating.

Because of these poor decisions there are a few problems that you'll need to overcome when using modules, specifically in dealing with naming conventions currently in place in the framework and how that can make autoloading more difficult. He has a concept he's worked up to try to help the situation - Epixa, a system for fully namespacing out modules so a simple directory structure correctly reflects the namespacing.