Making Traversable Interfaces the Right Way

In PHP, objects that implement Traversable can be used in foreach loops. Traversable can’t be implemented directly in userland (pure PHP) code and instead Iterator or IteratorAggregate have to be used.

But what if you’re defining an interface that’s iterable as part of its contract? Should your interface extend Iterator or IteratorAggregate?

iterator_or_iteratorag.php

<?php

interface Foo extends \Iterator
{
    // ...
}

interface Bar extends \IteratorAggregate
{
    // ...
}

Neither. Instead interfaces should extend Traversable directly.

extend_traversable.php

<?php

interface Spam extends \Traversable
{
    // ...
}

Since interfaces should be, for the most part, role based the clients of an interface shouldn’t care that Iterator or IteratorAggregate is used. They just care that they can iterate over an object.

Extending Traversable means that it’s up to the implementing class to choose the best way to accomplish its iteration. Just like it should be.

To implement an interface that extends traversable, the implementing class’s implements declaration should include Iterator or IteratorAggregate. The trick here is the ordering: Iterator or IteratorAggregate must come first.

good_traversable.php

<?php

interface Spam extends \Traversable
{
    // ...
}

final class Ham implements \IteratorAggregate, Spam
{
    public function getIterator()
    {
        return new \ArrayIterator(range(1, 10));
    }
}

Doing otherwise causes an error on PHP (but seems to work okay on HHVM).

bad_traversable.php

<?php

interface Spam extends \Traversable
{
    // ...
}

final class Ham implements Spam, \IteratorAggregate
{
    public function getIterator()
    {
        return new \ArrayIterator(range(1, 10));
    }
}