The PHP::Impact blog has posted a list of thirty classes and components that can make your PHP development life so much easier:

Simplicity and extensibility are the main reasons why PHP became the favourite dynamic language of the Web. In the last decade, PHP has developed from a niche language for adding dynamic functionality to small websites to a powerful tool making strong inroads into large-scale Web systems.

Their list includes software like:

• LINQ for PHP
• Doctrine
• HTML Purifier
• SimpleTest
• Phing
• PHP Security Scanner
• SimplePie
• Smarty

...and many more. Check out the full list for all sorts of useful tools.

Stefan Mischook shares a little question and answer he had recently concerning object properties in PHP.

The question asked about accessing properties outside the class and/or defining them as protected/private to prevent it. Stefan's response was basically:

Many OO techniques are designed for situations where you will have more than one programmer involved, now or later. By declaring variables as protected or private, you are adding security to the code base by forcing the use of getter and setter methods where you can control how objects are used.

In his latest blog post, Matthew Weir O'Phinney shares some of his newfound love for the Reflection API that PHP5 brings to the table:

When I first read about the Reflection API in a pre-PHP 5 changelog, my initial reaction was, "who cares?" I simply failed to see how it was a useful addition to the language. Having done some projects recently that needed to know something about the classes they are using, I now understand when and how it can be used.

It shines when you need to work with classes that may not be defined when you write your code -- any code that dispatches to other classes, basically.

To emphasize the point, he lists a few things you can do with the API, including determine if a method exists in a class and instantiate an object instance with a variable number of arguments to the constructor. He also includes a code example, showing a simple method of getting all of the methods on a class.

Some concepts of object-oriented design are harder to figure out that others for a budding programmer. Thankfully, there's articles like this one from DevShed to help fill in some of the gaps. Specifically, they focus on inheritance, polymorphism, and serialization in your PHP classes.

If you are working with classes in PHP, you will sooner or later encounter inheritance, polymorphism, and serialization. The ability to use these three will help speed up your code writing. This article covers how to use them, and more.

First off, they look at inheritance and working with child classes before moving on to polymorphism (similar functionality, different objects), calling functions statically, and serializing objects to make passing them around much easier.

Jacob Santos talks in this new blog post about something that, if added to PHP, just might be more trouble than it's worth - inner classes.

Inner Classes are contained in parent classes and offer a sort of namespace mechanism for the public and open private class data transfer for private subclasses.

The functionality is already available in other languages, but the question is whether it is needed in PHP. The short answer is no. With PHP execution model, it would further slow down and bloat PHP compilation.

He demonstrates their purpose with some simple examples but also gives the reasons why it would be a bad thing to try to include them, including the better choice of namespaces over inner classes.

Continuing on in their "PHP functions" series today, DevShed has posted this next step up the ladder, getting more advanced with the functions they're working with. This time, there's a focus on functions inside classes and creating the classes around them (a sort of introduction to object-oriented programming).

Continuing our PHP functions article, we move on to creating classes. Let me say right at the start that you can write perfectly effective and useful PHP code without creating classes or going into object oriented programming. Object oriented programming can be very powerful and PHP programmers are increasingly taking advantage of these capabilities, which have been greatly expanded since PHP4.

They start with the creation of a simple class - a human class with two $legs and two $arms. They show a simple display of this data and add another attribute to the class, one for hair color. They then capture the output they've been creating inside a function, report, and show how to execute it. Finally, they show how to use the special function that runs when the object is created - the constructor.

DevShed is wrapping up their "Overloading in PHP" series today with this last part - "Overloading Classes in PHP5".

It's time to move on and continue exploring the subject, since there are still a few additional topics that need to be covered. So, what's comes next now? All right, in this last part of the series, I'll be explaining how to overload classes specifically in PHP 5, which offers native support for overloading class members and methods, without having to explicitly call the PHP built-in "overload()" function.

They look first at using the __get method to replace __set in their previous code to save data out to a file. Then, to illustrate even more enhanced functionality, they implement __get and __set at the same time in a class, using them to grab values and set values to properties. Finally, they throw __call into the mix, showing how to overload method calls too.

Lukas Smith has a quick post today about some of the tension that's come up between to PEAR error handling packages and something he's created to try to help calm things down.

Well there is a lot of back and forth about if PEAR should mandate PEAR_Error or PEAR_Exceptions or neither for new packages. This also relates to the question of PHP5 E_STRICT compliance which PEAR_Error obviously is not.

His quick fix for the problem? Two proxy classes that would make switching between either of the two error handling classes as simple as changing out which proxy you're using.

Another very brief article has been posted by Justin Silverton today - this time, it's a "case study" of the hows and whys of Flickr using PHP/MySQL.

Carl Henderson from Flickr.com, a very popular photo blogging service has released a pdf (not sure exactly when this was actually released) detailing the issues they faced with having a high-traffic website.

Based on the original PDF, Justin pulls out some of the key points he noticed as he read. The top level items are "Classes, libraries, and systems used", "unicode support", "Why php was used", and "Mysql usage". He provides more of an outline for each item in the post, touching on the full contents of the formal case study.

Jim Plush wanted to try a little experiment with perfomance in PHP - specifically dealing with the placement of the class code in an application.

Out of sheer boredom I wanted to see which was better, including one big file of classes or splitting your classes up into multiple files. I'm going to use nusoap as an example. The NuSoap package lets you download one file. nusoap.php. That one file contains 9 classes. While not only is this method nice as you only need to include one class, its also 24% faster on average than having to include 9 seperate files.

In his informal testing he found that combining the files/classes into a single large file made for better performance (as far as object usage) - of course, that also makes it harder to maintain...