On his blog, Jaisen Methai posted about a very handy feature of PHP5 - the __autoload function.

It's one of the gems in PHP that I find to be relatively under used. It's common for PHP applications to break out classes into their own files. This becomes cumbersome when working on large projects as you wind up with numerous include/require calls for any given page.

He shows an example of its usage (loading class files dynamically from a specified directory) and mentions how it can help to make your code a lot less ugly. Comments on the post range in topics - from comparing it to include paths, how the idea was borrowed from PEAR, and how proper naming conventions can make its use even easier.

Padraic Brady has noted that the latest release candidate of the HTMLPurifier software has been posted for download:

HTMLPurifer is possibly the most understated underpublicised quality library in PHP today. I consider it a fundamental standard library that is automatically included in every PHP web application I start these days.

This latest release candidate (their first!) includes updates on two major features - the use of autoloading and a change to the way you use the filters. Check out a demo of it in action or just download this latest release and try it out for yourself.

On his blog Jan Lehnardt has posted an alternative method for using the Code Igniter framework together with the Zend Framework with only the parts you need.

I want to use Code Igniter for some applications and I want to use some bits of the Zend Framework inside my Code Igniter classes. There is a tutorial explaining how to set it up. But there is a problem.

He reverses the method the other tutorial uses and chooses to go with Code Igniter for the application logic side of things, making use of the helper and autoload functionality of CodeIgniter to pull things together. He includes code to make his method clear.

DevShed has posted the next part of their series looking at handling errors thrown by the __autoload functionality of PHP. This time they enhance their previous method and allow for custom error messaging.

In this last article of the series I'm going to introduce some additional modifications to the current signature of the "__autoload()" function to make it throw exceptions that display more useful error messages.

They start by setting up the application to have something to build from (a series of PHP scripts). They add on the exception handling to throw the custom error (the "class not found" they mentioned).

DevShed continues their looks at autoloading classes in PHP5 today with this new tutorial focusing on catching and handling any errors that might be thrown in the process.

This is the third article in the series on how to auto load classes in PHP 5. This article will demonstrate how to trigger exceptions in a way that can be caught by the corresponding "catch()" block. [...] Nonetheless, this issue can be fixed with relative ease. That will be the goal of this third article of the series. So if you're interested in learning how this solution will be implemented, don't waste any more time and start reading now!

They start by looking at throwing an exception with the __autoload so that the script can catch it. The go back to mention the method they'd talked about before - using just eval() - and then show the "new and improved" method of handling the result with a try/catch block instead of a direct output.

DevShed has posted the second part of their series looking at handling exceptions in a PHP5 application today. This one focuses on capturing the errors thrown when your script autoloads classes.

Bearing in mind this intrinsic limitation exposed by the "__autoload()" magic function when it comes to triggering exceptions at runtime, in this second article of the series I'm going to show you some basic workarounds that you can implement to provide this function with the ability to throw exceptions when a determined source class fails to be included.

They give two examples of the use of the __autoload function as well as a method to capture the fatal errors that it might throw (using an eval inside of it to check on the class).

On the I/O Reader blog, there's two different posts that take two sides of the spectrum when it comes to what to like and dislike about PHP, both lists of features of the the language:

• 15 Cool Things About PHP That Most People Overlook - a list including the Reflection API, the Standard PHP Library, type hinting and the "magic" functions.
• 12 Things You Should Dislike About PHP - this list includes things like naming conventions, that _tostring doesn't work as (he) expected, magic quotes and register globals and safe mode

Both have their valid points and it's interesting to see how many of the points made in the first article he goes back on and mentions specific instances where it doesn't work as expected. Some of the comparisons seem a bit like he's comparing PHP to his experience in another language and not objectively on PHP's features alone.

Spurred on by some previous benchmarks [pdf] from Ilia Alshanetsky, Joakim Nygard decided to run some his own benchmarks on the same sort of functionality.

There are numerous discussions in the blogosphere about whether to use echo versus print, if for() is faster than while(), etc. and though the gains are usually very small, I decided to add my thoughts to the debate. I found an article on optimization through coding habits in Ilia Alshanetsky's zend performance slides.

According to his results:

• Calling require_once() 10000 times in a for() loop with an empty file is 4x faster.
• With a simply autoload requiring a class and 10000 loops of new Foo() versus require_once('foo.php'); new Foo() shows that __autoload() is ~3.7 times faster.
• If a class method can be static, declare it static. Speed improvement is by a factor of 4.
• Avoid function calls within for() loop control blocks
• Always, always quote array keys.
• Get rid of 'harmless' error messages - they take time to generate and output.

I am not out to prove Ilia wrong - he knows PHP better than most - and for all I know, they could have optimized those very functions in PHP 5.2. [...] It would appear that there are improvements, albeit small, to achieve from minimal effort. Plus I was surprised by the discrepancies I found compared to Ilia's recommendations.

In this new post, Mike Wallner talks about making the move up from his PHP 4.4 environment straight up to PHP 5.2.

Anyway the only issue I really had, in spite testing the code really well over time, was with class_exists() and millions of warnings because of a missing __autoload().

The problem for him was caused by a combination of the new default behavior of the class_exists function and the autoload not included. He does note, thought, that APC works well with the new installation, though (and uses less memory).

In response to Terry Chay's response about his previous blog post, Frank Kleine has posted a few more comments on the topic of object serialization and some of the assertions Terry made.

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.