i for one have mixed feelings on this issue. im tempted to agree w/ nick, but not entirely. my stance is this; implementing the iterator or related interfaces is transparent to client code; namely you can still use for each to traverse the collection. you also get to do things during the iteration, that would have to be done in client space otherwise. now, this isnt always appropriate, maybe not even most of the time, but this is handy in many occasions; here is such an example; http://propel.phpdb.org/docs/api/1.3/runtime/propel-util/CriterionIterator.html furthermore; i like the idea of a named group object; not to the point of absurdity; eg; implementing strings in php, rob; i get you point, but there are plenty of uses for an aggregate object within reason. what is the most trivial examples i can think of.. classes for a database table.. suppose you have 2 classes per table; one that represents a record, another that represents a group of records; which ideally is an iterator. it makes sense to me, and ill take it over an array of record objects in this case. because what is an array of the record objects; its data; an array like any other; its not an instance of a class that specifically represents a collection of said records; so in order to identify them; youll have to inspect the elements. and aggregate functions, how would you implement those? any ones specific to the collection would go in the group class of said hypothetical implementation. and btw; your narratives are are just damned hilarious rob ;) -nathan
