The IteratorAggregate Interface

[iwato]

Background: Below you will find three sets of code including one class definition and two different, but similar applications of the same class. Both applications produce identical results, and both applications are the same in every way but one -- namely, the condition of each application's foreach-statement.Question: If the two expressions $student and $student->getIterator() produce the same result, then what is calling the getIterator() method when it is not present? Is there something built into the implemented interface that users cannot see or know?The Classs

<?php	class Student implements IteratorAggregate {		protected $info = array(			'first_name' => 'John',			'last_name' => 'Smith',			'email' => 'john@smith.com'		);			public function getIterator() {			return new ArrayObject($this->info);		}			}?>

Application One

<?php	$student = new Student;	foreach ($student->getIterator() as $info => $value ) {		echo "$info: $value<br />";	}?>

Application Two

<?php	$student = new Student;	foreach ($student as $info => $value ) {		echo "$info: $value<br />";	}?>

Roddy

[boen_robot]

When your object implements IteratorAggregate, you're forced to implement the getIterator() method and you're expected to return a traversable thing (e.g. an array, as in your case, or an object implementing Traversable).At the same time, when you pass the object to a foreach, the foreach method can see that your class implements IteratorAggregate and therefore has a getIterator() method. It expects you to implement it in the way you should, and therefore executes it, gets the result, and tries to loop over it.The reason why it's the same with or without calling getIterator() is simply because getIterator() is called whether you want to or not, as long as your class implements the appropriate interface(s), in this case IteratorAggregate.

[iwato]

The reason why it's the same with or without calling getIterator() is simply because getIterator() is called whether you want to or not, as long as your class implements the appropriate interface(s), in this case IteratorAggregate.

So, there is something built into the IteratorAggregate interface that we cannot see and that automatically triggers the getIterator() method.As suspected. Thank you for the confirmation, boen_robot.Slowly, but surely I am getting the hang of object-iterators.They are by no means intuitive.Roddy

[boen_robot]

Not exactly... there's something built into the foreach (not the interface) that we can't see that automatically triggers the getIterator() method when the right interface is detected.It's an odd (though not vital to know) distinction, as if (for example) resources were ever made traversable, that too would involve a change in the foreach... which is why it's not already done, and you see APIs returning traversable objects instead.

[iwato]

Not exactly... there's something built into the foreach (not the interface) that we can't see that automatically triggers the getIterator() method when the right interface is detected.

This makes still better sense, as up until now I have thought of interfaces as skeletons with no muscle. Thinking of the muscle in the foreach-statement makes a lot more sense and reinforces my older notions.Roddy