He explains the concept of "generators" as an easier way to implement iterators. In his example he shows how to refactor is file handling iterator to replace it with generator functionality. It uses a new keyword, "yield", to return a Generator instance that can then can be used much like the file iterator without the need for all of the code to create the iterator itself. His more complex example shows how to replace an ArrayObject instance by a little trick inside its "getIterator" method.

I help people qualify for Zend Certification and in the last few months I've had questions about both ArrayAccess and ArrayObject. This post is an attempt to illuminate both. In very simple terms, ArrayAccess is an interface, which you can implement in your own objects; ArrayObject, on the other hand, is a class, which you can either use or extend.

She give an example of ArrayAccess - a simple class that implements it to make it work like an array. For ArrayObject, she describes some of the things it comes with, including automatically implementing the ArrayAccess, Countable and Traversable interfaces making it a "more powerful array" type.

Here's a quick question for the wider PHP programming community '¦ if you're writing code that tests for the presence of an array, should is_array() also accept objects that behave like arrays?

Some quick code snippets show that, currently in PHP 5.2, an is_array test will return false. If you use an instanceof to check it, however, you can get it to return true. There's plenty of comments on the subject with quite a few "no"s in the group.

ArrayObject is an object that is designed to behave exactly like an array. If that seems confusing, don't worry, it's not. ArrayObject is an object. It follows all the rules of how objects work. But it's designed to implicitly behave like an array for all intents and purposes, including being used in a foreach loop, and accessing it's properties just like you would access the values in an array.

He includes a code snippet showing how the ArrayObject can be used and explains that, since it's an object and not an array, the "copy, not duplicate" handling applies to it. You get the best of two worlds - the ease of an array and the power of an object (plus there's some performance improvements too).

Today I will look at the Countable interface, it has a single function that needs to be implemented: count(), by implementing this you can ensure that there is a count() function ready to use on any given class that implements it. The Countable interface is used in other places in the SPL as well: the ArrayIterator and ArrayObject classes implements this interface ( and SqliteResult if present ).

In his code examples he shows simple methods for returning the count() of a property, but notes that the real power of it comes in the ability to manipulate the number returned from the call based on other parameters (or filtering).

I've been thinking about the Simple Zend_Form File Upload Example that I discussed last month. To recap, if you haven't read the comments, if the form fails to validate for some reason then you get a nasty error.

He corrects the issue by creating an ArrayObject (thanks to the SPL) that can be used both as an array and can look like a string to htmlspecialchars and changing up the validation a little bit to work with the new object.

Several weeks back, a bug was reported against Zend_View that had me initially stumped. [...] I'd read about this some months back on the php internals list, but at the time hadn't understood the consequences.

Basically, __get() no longer returns a reference and returns values in read mode, which makes modifying arrays using overloading impossible using traditional methods.

Unfortunately, this was exactly the functionality that was needed, so Matthew set out to find a way to do just that. His initial method, extending the ArrayObject, worked but still gave errors. On Mike Naberezny's recommendation, though, this too was resolved with a simple call to the __set method instead.

Assuming everyone knows what generics are, let's get down to business right away. PHP does not support generics or something similar, though it could be very useful in PHP development. Luckily, using some standard OO-practises, a semi-generic array can easily be created, even in multiple ways! Here's the road to PHP generics.

He shows the two ways to make generics possible - the hard way (simple inheritance and type hinting) and the more flexible way (a GenericArrayObject that extends the normal ArrayObject to make appending and validating the contents of the array simple).

Several weeks back, a bug was reported against Zend_View that had me initially stumped. [...] Basically, __get() no longer returns a reference and returns values in read mode, which makes modifying arrays using overloading impossible using traditional methods.

He gives a code example of the problem and two ways to get around it - one using a switch statement to get around the problem and the other ("best solution") was Matthew's option to extend the ArrayObject class.

As arrays are the only complex types that are passed by value (resources don't really count here) the solution to described problem is simple: use an object; either an instance of stdClass or ArrayObject will do well, depending if you want to use array index notation.

He includes two code examples, one just trying to overload it in a class with __get (yielding an error) and the other using the constructor to pass an ArrayObject out first, allowing for error-free assignment.