The Filter Iterator is probably my second favorite iterator, next to Directory Iterator. There are many great use cases for the Filter Iterator, and when you do filter the original data is left untouched. A Filter Iterator is really simple to use, create a class that extends FilterIterator and adjust the accept method to meet your criteria. This is great and all, but having the ability to create filter iterators on the fly, ones that won't be used application wide, without having to create a class is even better.

He includes a bit of code defining a FilterCallbackIterator class with a "callback" parameter passed into the constructor (in his case, a closure). Also included is some sample code of it in use - handling an array (well, ArrayIterator) with a simple true/false check on the current array value. You can find out more about this functionality in the PHP manual.

We were talking about why some of the SPL Iterators accept only an Iterator as the constructor argument (Such as LimitIterator), and others accept either an Iterator or an IteratorAggregate as the argument (Such as IteratorIterator). Feeling that this would be a useful feature to add (having all of them accept an IteratorAggregate), I opened up the PHP source and started looking at how hard of a change this would be. What I found was... Interesting...

He shares some of the C code he came across in his investigation including a "WTF" moment when he found a case statement for DIT_IteratorIterator in a constructor. Because of some of the logic in this constructor, the inputted iterator is "cast down" to a class. This is shown in a few code examples comparing simple iteration objects and arrays and how it seems to be able to bypass class inheritance to use methods from other classes.

To start illustrating why segregated interfaces are really useful, in the lines to come I'm going to build an example that will recreate the scenario described in the introduction. Basically, what I want to achieve here is to construct a custom countable array collection.

He shows the basic class structure needed to emulate a countable array in an object by implementing the "Countable" interface. He adds in the "Iterator" interface to allow you to work with the dataset like an array - progressing through it, rewinding to the beginning and checking to see if a value exists. Finally, they add the "ArrayAccess" interface to the class that boosts it with even more features like the ability to grab things by specific keys (numeric or string). The finish the article off with an example of an ArrayCollection object and how it can be looped through using a foreach.

Recently I needed to process a huge array of data and because of PHP's somewhat inefficient variables and especially arrays that was resulting in "out of memory" errors. However, I couldn't use any other tools than PHP so was forced to come up with a solution implementation in it. Here is how I solved it using principles from functional languages.

He gives an example using Haskell to generate a Fibonacci sequence using its built-in lazy evaluation abilities. Unfortunately, PHP doesn't have such a thing built in, so he tries the next best thing - Iterators. He caries the idea over to the database side too, recommending fetch() in a loop over fetchAll() and some effective joins.

In my previous post, Simple Object Iterators in PHP, we discovered how to iterate over array items defined within an object using a foreach loop. However, what if you need to iterate over items which are not stored in an array, e.g. records from a database or lines of text read from a file?

He shows how to create a script that pulls in the users from a database object (PDO, in this case) and implements the Countable and Iterator interfaces. These interfaces give it some special methods that can give counts of the results and help you iterate through the results - current, rewind, next and valid.

If you've been coding in PHP for a while, you may be familiar with the foreach loop. It provides an easy way to analyze every item in an array. As well as arrays, it's also possible loop through an object. If your object contains a collection of items, you can use a foreach loop to iterate over each of them. [...] Iterators is a subject which strikes fear into the heart of many developers. They sound complex and are often explained with indecipherable abstract references.

To help combat this impression, he gives a bit more practical example - turning a regular array into an ArrayIterator and looping through the collection as an object instead of just a variable. This helps to keep things contained.

One of the things I have been working on lately was a simple XML parser. It's a simple XML structure in my case though it could be more complex without much change. My solution was a quite powerful yet simple combination of XMLReader and the Iterator interface.

He includes a sample XML document similar to the one he was working with and shows how XMLReader can handle it, keeping only the currently needed information in memory at one time. His sample class (CustomXml) loads the file and defines all of the iterator methods to work with the data like "next", "prev" and "rewind".

If you are doing any data processing whatsoever you are using arrays. And most likely you are doing database queries, iterating over the results and doing your algorithm-ing. But what if you have additional functionality that you need to have integrated with your data. You could go the traditional route and copy and paste half your application around or you could build, what we like to call structured applications. SPL allows you to do that.

In the excerpt he mentions the methods that come built in to Iterators like rewind, current and valid. There's also some sample code showing a custom iterator that works with some user data to output the information set in the constructor. You can find out more about this chapter and the rest in Kevin's book.

I'm currently doing research and prototyping for autoloading alternatives in Zend Framework 2.0. One approach I'm looking at involves creating explicit class/file maps; these tend to be much faster than using the include_path, but do require some additional setup. [...] I'm well aware of RecursiveDirectoryIterator, and planned to use that. However, I also had heard of FilterIterator, and wondered if I could tie that in somehow. In the end, I could, but the solution was non-obvious.

He starts with what he thought he should be able to do with the FilterIterator - pass in a DirectoryIterator to be able to filter them recursively. Unfortunately this only worked for the first level, so he looked else where. His solution ultimately involved passing in a RecursiveIteratorIterator instance into the DirectoryIterator that contained his RecursiveDirectoryIterator. He includes a full code example in the post showing how to locate a certain file/class recursively inside a directory.

In the back end, we have models that connect to CouchDB. These models implement the Iterator pattern to allow easy traversal of a record's keys. [...] Little did I realize that this implementation is very broken. [...] Over the past few years, I've implemented many iterators in this way, using PHP's implicit array manipulation functions (reset(), current(), key(), next()).