I believe the correct solution to this is an OuterIterator — an
OuterIterator contains the logic to constrain the loop, for example, we
have the LimitIterator, FilterIterator, RegexIterator, etc.

See this example:
http://php.net/manual/en/class.limititerator.php#example-4473

You can build your own OuterIterators, which implements whatever logic your
Reader should have.

OuterIterators are also compose-able, you can stack them, though of course
there are performance considerations here.

I would say that any alternative to OuterIterator's should have a clear and
demonstrable benefit in both developer experience, and performance before
it should be considered.

- Davey

On Wed, Jul 5, 2017 at 3:51 AM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> On 3 July 2017 16:58:16 BST, Andreas Hennings <andr...@dqxtech.net> wrote:
> >My motivation was to be able to use iterators and readers
> >interchangeably.
> >Readers are easier to implement as classes.
> >Iterators have the benefit of the generator syntax.
> >The idea is to have a library where some stuff is implemented as
> >reader classes, and some other things are implemented as iterator
> >classes.
> >
> >Then for the actual operational code, I need to choose to use either
> >iterator syntax or reader syntax. So either I need adapters for all
> >iterators, or I need adapters for all readers.
>
> An alternative to adapters in this case might be a Trait that allows you
> to write the class as a Reader, but turn it into a fully-functioning
> Iterator with one line of code. If you always call your read method read()
> you only need a single adapter which calls that at the appropriate times
> and buffers the value to know if it's reached the end. That adapter could
> be "pasted" by a Trait into each class where read() is defined, and read()
> could even be private.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Reply via email to