class FileFilterIterator extends FilterIterator { function accept() { return $this->current()->isFile(); } } $Reader = new FileFilterIterator(new DirectoryIterator('./')); // Loop through the files in the directory ?!? foreach ( $Reader as $Item ) { echo $Item.'
';

As a side note, been wondering why an abstract OuterIterator class wasn’t created in spl.

abstract class OuterIterator implements Iterator { protected $iterator; function __construct(Iterator $iterator) { $this->iterator = $iterator; } function getInnerIterator() { return $this->iterator; } function valid() { return $this->iterator->valid(); } function key() { return $this->iterator->key(); } function current() { return $this->iterator->current(); } function next() { return $this->iterator->next(); } function rewind() { return $this->iterator->rewind(); } }

which then iterators like FilterIterator would have been subclasses of.

Cant guarantee Ill do the same in future – to me, as a European, there was nothing offensive about the title – didnt even occur to me. If I start thinking about every possible culture I might offend, nothing would get written.

As a side note, been wondering why an abstract OuterIterator class wasn’t created in spl.

Thats an interesting question – guess we’d need Marcuss input on that. Talking to him and studying the design I’m very sure he had clear ideas in building the SPL iterators; the problem is I doubt he’s going to get time to explain all the decisions that influenced the design, which would help alot.

Perhaps you could propose it to him, with a use case?

Your idea is not bad but you lost the subdirs. You need to use
RecursiveDirectoryIterator instead of DirectoryIterator. Then you
need to iterate that with RecursiveIteratorIterator and that with
a filter iterator. The last being something like the opposite of
ParentIterator or one that uses your accept().

The outeriterator is an idea both Andi and me had. However it got
lost somewhen because i didn’t fint it to important and i would
not allow access to the inner iterator by property. Instead i
would make that a private one and provide a function based
access. Also it doesn’t need to be abstract in your case but i
want that so i can still have c implementations. As a consequence
i’d do it in an Interface. Putting those ideas together gives teh
following:

interface OuterIterator extends Iterator
{
abstract function getInnerIterator();
}

and then maybe have a class IteratorIterator like your one which
implements OuterIterator :-)

I’m finding the general class helpful thou, especially when mapping either key() or current() return values to something else.