WP_Query implements IteratorAggregate

[hakre]

Giving WP_Query the IteratorAggregate interface would allow to deal with it more fluently the "PHP way". This is especially true for themes.

[hakre]

Related: #20296

[johnbillion]

What would be the use case for this? You can iterate over member variables of an object without an iterator interface, so what exactly does this do?

[nacin]

In theory, I really like #20296 and #20297. They could significantly simplify how a loop looks. Instead of $query->have_posts() : $query->the_post(), it could be foreach ( $query as $post ). Perhaps when combined with WP_Post, they could be very powerful.

A few practical issues, however. For the main loop, you'd need to use foreach( $wp_query ) -- directly accessing a global is worse than the template tags we have now -- unless of course we introduced a wp_query() function. Also, without WP_Post (which we definitely don't have), it's not that helpful, especially if it doesn't call the_post() automatically on iteration. Also, if it doesn't implement Countable (which it can't as SPL can be disabled before 5.3), it would only be confusing for it to implement IteratorAggregate.

I like the idea. I just don't think we're at the point yet where we should do this. Especially since it is just as easy, for now, to run foreach() and count() on $wp_query->posts. I suggest closing it as maybelater.

[scribu]

If we were to implement IteratorAggregate and ArrayAccess, we could make get_posts() just return the WP_Query instance, but that won't be much help if we still have to deal with setup_postdata().

So, yeah, WP_Post first.

[hakre]

Yes, IteratorAggregate is a light approach here. The patch is available so it's something to play with. I also thought about the shortcomings because of setup_postdata, a much nicer thing would be to have WP_Query and an Iterator for it which can replace the ArrayIterator - an external iterator still aggregated. However I wanted to keep this first suggestion light, I think WP_Query is a potential class that could benefit from PHP's traversable features and that's the main point.

Sure this little patch can't do all the magic - would be cool, but as noted, it does not show the whole picture.

If there's something like WP_Post I think there would be some list-class like WP_Posts which is traversable anyway.

Maybe using an iterator internally in WP_Query will make future changes more feasible.

About compilter flags: The SPL is compiled in with nearly every standard distribution. As with any other compile feature, things can be disabled which are commonly not, but we don't care much about all those other compile flags as well. Just to put this into the right light, the SPL ain't some esoteric feature, it's generally available with PHP 5.2 and above so it's really safe to use.

[nacin]

I like the idea. I just don't think we're at the point yet where we should do this. Especially since it is just as easy, for now, to run foreach() and count() on $wp_query->posts. I suggest closing it as maybelater.

[hakre]

Example of a WP 3.6 compatible iterator for posts of a WP_Query: ​https://gist.github.com/hakre/6520715